By default, the IIS server is set to show detailed errors for local requests only, whereas it displays a custom error page for remote requests. This is done for security reasons, since detailed errors could reveal potentially detailed technical information about the web server and website.
Contents
- Why are detailed errors important?
- Enabling detailed errors using the IIS manager
- Enabling detailed errors using the web.config file
- Author
- Recent Posts
Surender Kumar has more than twelve years of experience in server and network administration. His fields of interest are Windows Servers, Active Directory, PowerShell, web servers, networking, Linux, virtualization, and penetration testing. He loves writing for his blog.
Surender Kumar has more than twelve years of experience in server and network administration. His fields of interest are Windows Servers, Active Directory, PowerShell, web servers, networking, Linux, virtualization, and penetration testing. He loves writing for his blog.
The detailed errors also reveal HTTP substatus codes, which are helpful in debugging complex issues. The bad guys out there could use this information to conduct attacks on a web server or website. That is why the IIS server only shows a custom error page for remote requests by default.
Why are detailed errors important?
As discussed above, detailed errors are important when you want to debug a problem in a website hosted on a server running IIS. The custom error page shows an error message that is usually ambiguous. Let’s have a look at the two screenshots below:
403 Forbidden Access is denied error using custom error page
The above screenshot shows a typical 403 – Forbidden: Access is denied error using the custom error page displayed by IIS. It is not very helpful for website administrators. Now, let’s have a look at the following screenshot:
403.14 Forbidden error with detailed error mode enabled
This screenshot shows the same error with detailed error mode enabled. Now, it shows plenty of useful information that an administrator can use to identify the cause and fix the problem.
Enabling detailed errors using the IIS manager
To enable detailed errors:
- Open the IIS manager by pressing WinKey+R, typing inetmgr, and pressing Enter.
- Expand the Sites node and select the website for which you want to enable detailed errors.
- Under the IIS section in the Features View, double-click Error Pages (see the following screenshot).
Locating the error pages section in the IIS manager
- In the Actions pane on the right, click Edit Feature Settings.
Enabling detailed errors in IIS manager
- In Error Responses, you will see three options:
- Custom error pages
- Detailed errors
- Detailed errors for local requests and custom error pages for remote requests (default)
- Now select either the second or third option and click OK.
Viewing the detailed error modes in IIS
Since you can directly access the web server using remote desktop, selecting the third option is best. Now, you can open the web browser on the server itself and try to load the problematic webpage to see a detailed error page containing more technical information. By doing this, you’re not enabling the bad guys out there to view the detailed information, since the detailed error is only displayed for local requests.
Enabling detailed errors using the web.config file
There are situations in which you cannot use the IIS manager to enable detailed errors. For example, if your website is hosted on a shared hosting site, you won’t have access to the IIS manager. In such scenarios, you could enable detailed errors using the web.config file, which is usually located in the root directory of the website. Just add the following line inside the <system.webServer> tag:
<httpErrors errorMode="Detailed" />
Enabling detailed errors using web.config file
Remember that by adding this line to the web.config file, you are forcing IIS to throw the detailed errors for local or remote requests.
Subscribe to 4sysops newsletter!
Once you identify the root cause of the problem, it is always recommended to disable detailed errors to prevent your website from revealing sensitive information.
| title | author | description | ms.date | ms.assetid | msc.legacyurl | msc.type |
|---|---|---|---|---|---|---|
|
How to Use HTTP Detailed Errors in IIS 7.0 |
rick-anderson |
Every Web-Site Administrator or Web Developer has seen ‘404 — File not found’, ‘401 — Unauthorized’ or ‘500 — Server Error’ messages in his browser. This ar… |
12/12/2007 |
33897393-97b8-4ee1-836f-25b1348dc3a3 |
/learn/troubleshoot/diagnosing-http-errors/how-to-use-http-detailed-errors-in-iis |
authoredcontent |
by IIS Team
Introduction
Every Web-Site Administrator or Web Developer has seen «404 — File not found», «401 — Unauthorized» or «500 — Server Error» messages in his browser. This article helps you understand how and why IIS generates these errors and how they can be configured.
Many might think that generating error messages does not seem to justify a full article. But there is more to errors than meets the eye. Error messages are a sensitive topic, because every error reveals more about your web-site than you might want revealed. The more information someone can gather about your site, the likelier it is that you will be hacked. A search for «google hacking» or «cross-site scripting» reveals a wealth of information on this topic.
However, error messages are also a valuable tool to troubleshoot problems. Developers and Web-Site Administrators require as much detail as possible when an error occurs. Ideally the error message gives recommendations on how to fix the problem. Here is how IIS addresses these fundamentally opposed goals.
Errors, What Errors?
This article talks about HTTP errors as specified in the HTTP RFC (RFC 2616 — section 6.1.1). An HTTP error is always expressed by sending a response with a status code greater than 400 back to the requesting client.
Client Errors
Status codes between 400 and 500 specify an error that the client made, e.g. bad syntax or a request to a resource that doesn’t exist. You can try this by requesting a bogus URL from the web-site of your choice, for example: http://<IIS7Server>/this_resource_does_not_exist. You get a «404 — File not found» error.
Server Errors
Status codes starting with 500 are errors caused by the server. The most common causes for 500 errors on IIS systems are:
- An ASP or ASPX page that contains a syntax error
- The web server configuration or the application configuration cannot be read or is invalid
- The site is stopped
It is important to note that browsers like IE often replace errors returned from a web server with their own errors. This makes troubleshooting harder. In IE you can turn this feature off. Go to the «Tools» menu, select «Internet Options», click the «Advanced» tab and find the «Show friendly HTTP error messages» check box and uncheck it. To see the raw response, use HTTP tools like WFETCH in the IIS 6.0 Resource Kit (see «Related Links»).
HTTP Errors in IIS
There are two things that can happen when the httpError module (custerr.dll) encounters an error:
- A custom error is generated
- A detailed error is generated
Custom errors are error pages that the regular users of your web-site see. They contain a brief error description of why the error happened, but nothing else. Here is the custom error generated when you request a resource that does not exist, for example: http://<IIS7Server>/this_resource_does_not_exist
Detailed errors are intended for local administrators and developers. They are supposed to provide information that helps to immediately fix the problem. Here is an example of the same request, but now returning a Detailed Error:
This is dangerous, because Detailed Errors contain information about the inner workings of your web-site. Only trusted personnel should see a Detailed Error. The only way to ensures this is to only generate a detailed error if the request comes from the local machine. As soon as the request is not local, a custom error is generated. Look at the following flow diagram:
Data Flow
First: Error check
The httpError module receives a notification if a response is about to be sent (RQ_SEND_RESPONSE notification). The httpError module checks the status code of this response and immediately returns if the status code is not greater than 400.
Second: Custom Error or Detailed Error
The next check is determined by the request origin (is the request a local or remote request) and the setting of the errorMode property. The errorMode property is set to DetailedLocalOnly, which means that Custom Errors are generated for every remote request. If errorMode is set to «Custom», then all error responses will become Custom Error. If errorMode is set to «Detailed» all error responses will become Detailed Errors. The following table clarifies this behavior:
| errorMode | Request origin | Action |
|---|---|---|
| DetailedLocalOnly (default) | Local | Detailed Error |
| DetailedLocalOnly (default) | Remote | Custom Error |
| Custom | Local | Custom Error |
| Custom | Remote | Custom Error |
| Detailed | Local | Detailed Error |
| Detailed | Remote | Detailed Error |
If the httpError module determines that a Custom Error must be generated, it looks into its configuration to see if it can find a matching error. If a match is found, it sends the static file, redirects the request or executes the URL specified. If no match can be found, IIS send a basic one-line message containing the status code. The next section explains the Custom Error configuration in detail.
If custerr.dll determines that a Detailed Error must be generated, another check is needed. IIS does not touch the response if a module overrode the entity of the response with its own error description. It might contain valuable information. ASP.NET is a good example. The entity of an ASP.NET error response might contain the exception stack and its own error description. A Detailed Error is only generated if the entity body of the response is empty.
<httpErrors> Configuration
Here is the IIS custom error section obtained on a clean install:
[!code-xmlMain]
You see that if the status code of a response is 401, IIS will return a file named 401.htm.
Sub-Status Codes
Many HTTP errors have a sub-status. The IIS default Custom Errors configuration does not differentiate based sub-status codes. It sends the same Custom Error page if you enter the wrong credentials (401.1), or if you get access denied based on invalid rights to access a file (401.3). You can see the different sub-status codes in the log files or via Detailed Errors. Here is a list of the different 404 sub-status codes that IIS produces:
| Status | Description |
|---|---|
| 404.1 | Site could not be found |
| 404.2 | Denied by Policy. The request ISAPI or CGI program is not allowed in the Restriction List. |
| 404.3 | The static file handler did not have the file in its MimeMap and therefore rejected the request. |
| 404.4 | No handler was found to serve the request. |
| 404.5 | The Request Filtering Module rejected an URL sequence in the request. |
| 404.6 | The Request Filtering Module denied the HTTP verb of the request. |
| 404.7 | The Request Filtering module rejected the file extension of the request. |
| 404.8 | The Request Filtering module rejected a particular URL segment (characters between two slashes). |
| 404.9 | IIS rejected to serve a hidden file. |
| 404.11 | The Request Filtering module rejected a request that was double escaped. |
| 404.12 | The Request Filtering module rejected a request that contained high bit characters. |
| 404.14 | The Request Filtering module rejected a request with a URL that was too long. |
| 404.15 | The Request Filtering module rejected a request with a too long query string. |
| 413.1 | The Request Filtering module rejected a request that was too long (request + entity body). |
| 431 | The Request Filtering module rejected a header that was too long. |
You can configure the httpErrors section to show a Custom Error for particular sub-status codes. If you add the following line to the httpErrors configuration section, IIS returns 404_3.htm if a file with a file extension is requested that is not included in the IIS MimeMap (<staticContent> configuration section).
[!code-xmlMain]
Here is how to make the example work:
- Add the entry above to your httpErrors configuration section.
- Create a file named 404_3.htm in your
c:inetpubcusterren-usdirectory. - Create a file named test.yyy in you
c:inetpubwwwrootdirectory. - Now request
http://localhost/test.yyy.
The file extension .yyy is not part of the IIS MimeMap and the static file handler will not serve it.
New in IIS: Language-specific Custom Errors
Each more recent browser includes the language of the client as a request header. Here is an example of how this header might look:
[!code-consoleMain]
The syntax and registry of accepted languages is specified in RFC1766.
When generating an error, IIS takes this header into account when it looks for the custom error file it returns. It generates the path for the custom error using the following logic:
prefixLanguageFilePath configuration setting (for example c:inetpubcusterr)+
Accept-Language header sent by the client (for example en-us) +
Path configuration setting (for example 404.htm)
Example:
If the browser sends a request for an non-existing resource and the «Accept-Language» header has the value of «en-us,» the file that gets returned will be c:inetpubcusterren-us404.htm.
For example, if you are from Germany, you want your error messages in German. To do this, you must install the Windows Vista Language Pack for German. This creates the c:inetpubcusterrde-DE directory with custom error files in it. Now if the browser sends the «Accept-Language» header with the value of «de-DE, the file that gets returned will be c:inetpubcusterrde-DE404.htm.
IIS will always fall back to the system language if the directory «de-DE» does not exist.
[!NOTE]
Internet Explorer allows you to configure the Accept-Language header. Go to «Tools» — «Internet Option», select the «General» tab and click the «Languages» button.
Custom Error Options
In the above examples, IIS sends the contents of the file as the custom error response. IIS has two other ways to respond to an error: by executing an URL or by redirecting the request.
ExecuteUrl
If you want to do more in your custom error, e.g. sending an e-mail or logging the error to a database, you can execute an url. This allows you to execute dynamic content like an ASP.NET page. The example below replaces the 404 custom error. Now IIS executes /404.aspx whenever a 404 error occurs.
[!code-xmlMain]
Security Considerations
A word of caution: For architectural reasons, IIS can only execute the URL if it is located in the same Application Pool. Use the redirect feature to execute a Custom Error in a different Application Pool.
IIS can also return a 302 Redirect to the browser when a particular error occurs. Redirect is good if you have a server farm. For instance, you can redirect all your errors to a central location that you closely monitor.
There is risk however: responseMode=»File» (which is the default) allows you to specify every file on the disk. This will not work if you are very security conscious.
A workable scenario might include only allowing the delegation of the errorMode setting. This enables a developer to receive Detailed Errors for his application even if he is using a remote client. All that is necessary is to set errorMode=»Detailed». Here is how to configure this scenario:
Allow the delegation of the httpErrors section:
[!code-xmlMain]
Second, go to the <httpErrors> section in applicationHost.config and change it so that only errorMode is delegated:
[!code-xmlMain]
Summary
Custom and Detailed Errors are powerful IIS features. They help you to troubleshoot problems without compromising the security of your IIS Server. Many configuration options help you to custom tailor your users’ experience. Most importantly: experimenting with it is fun.
See also
- Troubleshooting Common IIS Errors
Мы описывали как настраивать веб-публикацию на IIS в инструкции.
Но после настройки веб-публикации при подключении к базе может возникать ошибка “Ошибка HTTP 500.0 — Internal Server Error”.
Если модуль был установлен с 32-битного клиента, то требуется это указать в пуле приложений. Для этого мы делаем следующую настройку:
- Заходим в Панель управления → Администрирование → Диспетчер служб IIS.
- Выбираем Пулы приложения которые задействованы в веб-публикации, в нашем случае DefaultAppPool.
- Нажимаем ПКМ Дополнительные параметры.
- В строке Разрешены 32-разрядные приложения мы указываем True как на Рисунке 1.
- Нажимаем ОК.
Рисунок 1 — Дополнительные параметры пула приложений
Если не сработало, есть следующие возможные решения:
- Убедитесь, что разрешения NTFS для файла web.config верны и обеспечивают доступ к учетной записи компьютера веб-сервера. Заходим в директорию, где размещена публикация (по умолчанию — C:inetpubwwwrootИМЯ_БАЗЫ). Нажимаем ПКМ на web.config → Свойства → Безопасность. Убедитесь в том, что у группы IIS_USERS есть права на чтение, выполнение, запись и изменение файла. Если нет — нажмите кнопку Изменить, в появившемся окне Добавить → Дополнительно и найдите в списке IIS_USERS. Добавьте эту группу и назначьте соответствующие права.
- Проверьте журналы событий, чтобы посмотреть, была ли зафиксирована какая-либо дополнительная информация. Открываем Выполнить (ПКМ на кнопку меню пуск или сочетанием клавиш Win+R), вводим “eventvwr.msc”, нажимаем Enter. Возможно, журнал даст подсказку какой компонент может сбоить.
- Переустановите компонент IIS на сервере. В диспетчере серверов удалите роль Веб-сервера IIS, перезагрузите сервер, а затем установите заново через оснастку Добавить роли и компоненты.
- Установите компонент расширения .NET, если запрос сопоставлен управляемому обработчику.
В Windows Server 2012 и младше: заходим в Диспетчер серверов → Добавить роли и компоненты → Роли сервера → Веб-сервер (IIS) → Веб-сервер → Разработка приложений → Расширяемость .NET. Далее идём далее по указаниям системы.
После применения настроек, мы можем подключаться к настроенной веб-публикации без ошибок.
Нужна готовая настройка веб-доступа к 1С? Попробуйте наш сервер 1С в аренду, в услугу включены все настройки и обслуживание.
So you just moved your application to an IIS7 server, and now you are getting an error when you make a request to it. This seems to be a popular theme on IIS.NET forums these days, and after answering a hundred or so of these posts, I figured I should do something to help people track down and fix their issues with a little less frustration.
Dealing with 500, 503 IIS errors? These are likely hiding bigger application issues that are hurting your application.
It can be very hard to link generic IIS errors to underlying issues that you can fix. Head over to LeanSentry to get a comprehensive application checkup. We’ll find your actual IIS and ASP.NET issues, and even show you how to fix them in code.
Server software, and web servers specifically, are very complex and highly configurable systems that support multi-tier applications using a variety of technologies and subsystems, and endure further complexity due to security, performance, and reliability demands, so it’s a wonder it all works as well as it does in the end. IIS7 strives to improve the experience of diagnosing and solving problems when they do occur, so knowing how to use the new IIS7 diagnostics features can come a long way in helping you become a pro at troubleshooting server problems.
First things first – what’s the problem?
I often find myself asking this question on the forums when someone posts something like “Help, I moved to IIS7 and now my application doesn’t work!”. Huh, what doesnt work? When your site stops working, the first thing you need to do is determine what the error actually is before we can move any further. IIS7 has much better error messages that will often tell you exactly what the problem is, and help you fix it.
Unfortunately, sometimes getting to this error is the main challenge. Let’s look at a few things you may need to do to get there:
1) Disable IE “Friendly HTTP error messages”
IE will by default replace the actual error messages coming from the server with a “friendly” error message, which hides the error contents we need to see. For example, for a 404 Not Found error, you may instead see the following:
To disable this and see the real error coming from the server, you need to go to “Tools > Internet Options”, choose the Advanced tab, and clear the “Show friendly HTTP error messages” checkbox. Then, close the browser, open it again, and re-request the page.
Now, suppose you are still seeing the generic “cannot display the webpage” or “page not found” error. This is typically caused by IE failing to connect to your website, so there is no server error message to look at here. I have a detailed guide to troubleshooting this condition here: Where did my IIS7 server go? Troubleshooting “server not found” errors.
An aside: If you don’t want to mess with IE for troubleshooting (especially if you suspect you are getting cached pages, due to IE’s super- aggressive caching), the best thing to do is break out a trusty simple http tool of choice and make the request with it. I recommend WFETCH, which is included in the IIS6 Resource Kit tools (you can install on XP/Windows 2003 only, and can either run it from there or copy wfetch.exe to your Vista/LHS box).
2) Enable IIS7 detailed errors
IIS7 introduces a new custom errors feature, which by default hides the error responses issued by the server to remote clients, replacing them with a basic error message. This is critical for security of your site, as errors frequently contain sensitive information that you don’t want others to see, but makes getting to the bottom of the problem harder since you cannot see those very error details. So, if you are requesting your site from another machine, you may still get a basic error that looks like this:
You have two options here:
1) Make the request locally from the server machine.
By default, you will get the detailed error.
2) Enable detailed errors for remote clients.
First, if your error is an ASP.NET exception (you can tell if it says “Runtime Error” and has the framework version), please be aware that ASP.NET overrides the IIS custom error mechanism with its own implementation of custom errors, so you should turn the ASP.NET custom errors off to see detailed ASP.NET exceptions. You DO NOT have to configure IIS7 custom errors for ASP.NET exceptions (it would be silly to have to do it in two places). To turn off ASP.NET custom errors, place the following in your web.config:
<system.web>
<customErrors mode=”Off” />
</system.web>
If the error is not an ASP.NET error, turning off IIS7 custom errors will allow error responses from your application to be sent to remote clients without being censored by the IIS7’s custom errors module.
You can do this from the IIS7 Admin tool by running “Start>Run>inetmgr.exe”, selecting your website/application/virtual directory in the left-hand tree view, clicking on the “Error Pages” icon, clicking “Edit Feature Settings” action, and then selecting “Detailed Errors”.
You can alternatively do this from an elevated command line prompt (Run as Administrator):
> %windir%system32inetsrvappcmd.exe set config “Default Web Site/yourapp” /section:httpErrors /errorMode:Detailed
Where “Default Web Site” should be replaced with your site’s name if different, and “/yourapp” with the virtual path you’d like to enable detailed errors for.
NOTE: When you are done debugging, please return the settings back to custom errors for remote requests, or the security of your website may be compromised. Here is how to do it with AppCmd:
> %windir%system32inetsrvappcmd.exe set config “Default Web Site/yourapp” /section:httpErrors /errorMode:DetailedLocalOnly
Now, you should be getting detailed errors back – for example, the error I was getting before now looks like this (this is the Vista error page – Longhorn Server and Vista SP1 error pages will look much nicer, see this for an example):
Notice that this error contains quite a bit of useful information:
1) The heading contains the substatus code, 404.0, which is an IIS specific code that further describes the problem. The majority of common errors has a unique <status_code>.<substatus_code> combination that you can easily google for additional information.
2) The page indicates what module (IIS Web Core), and in what notification (MapRequestHandler) an error occurred. This information is critical whenever you are debugging server problems, especially on the IIS7+ world when most of them occur in one of the modules that take part in the processing of the request.
3) The page shows you some useful request information, such as the requested url and the physical path to which it resolved. Most 404 errors will be resolved right here, by seeing that the request is being made to a wrong url or resolving to a wrong physical path due to incorrect virtual directory mapping.
4) The “most likely causes” and “what you can try” sections offer the most likely explanation for the error and what you can do about it. They are dead on for the majority of common IIS7 errors.
NOTE: When you are coming to the forums with an error, we expect you to have gotten this far and that you will provide the detailed error to help us with your problem. For more information about the custom errors support in IIS7, check out http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Diagnostics-in-IIS7/Deciphering-Error-Messages/How-to-Use-HTTP-Detailed-Errors-in-IIS7.
3) Detour – the 503 “Service Unavailable” error
Sometimes, you will get an error that looks like this:
This error most likely either indicates a critical misconfiguration of the server that is causing IIS to fail to start a worker process/process your request, or a system overload condition that is causing requests to be rejected early, so no further error information will be available in the response. If you are getting this error, please follow my detailed guide: Where did my IIS7 server go? Troubleshooting “service unavailable” errors.
Deeper diagnostics with Failed Request Tracing (formerly known as FREB)
If the error alone is not sufficient to diagnose the condition, or more information is needed to determine what lead up to the error occurring, or, there is no error (for example, request times out), you can take advantage of the wonderful IIS7 feature called “Failed Request Tracing”.
This feature can be used to generate a detailed trace of events leading up to the failure, much like ETW, but now with more/more useful events and significantly easier to turn on and use for troubleshooting.
More importantly, you can configure Failed Request Tracing to only trace requests that encounter a specific failure condition, such as a specific response status/substatus codes, an event of specific verbosity, or a timeout.
To do this, you are going to need to install it first (if you haven’t already):
On Vista: Control Panel, Programs, Turn Windows Features on or off, check Internet Information ServicesWorld Wide Web ServicesHealth and DiagnosticsTracing.
On Windows Server 2008: Start>Run>Server Manager, Roles, Web Server(IIS), Add Role Services, check Web ServerHealth and DiagnosticsTracing
Then, to enable IIS to generate these logs, you need to do two things:
1) Enable Failed Request Tracing for the site you want to trace
In InetMgr, select your site in the left-hand tree view, then under Actions on the right click “Failed Request Tracing …”. There, select the Enable box.
2) Create a Failed Request Tracing rule with the events and failure definition of choice
In InetMgr, select the site/application/virtual directory that you’d like to trace in the tree view, click the “Failed Request Tracing Rules” icon, click the “Add…” action, and follow the wizard to create the rule.
You will be asked what content you’d like to trace (based on an extension), when to consider the request as failed (a list of response status codes, and in Longhorn Server, also event verbosity) or a timeout, and finally the events you’d like to trace. I recommend to leave all events selected by default, unless you are sure you know what you are looking for.
Now, when you make a request, if it meets the failure definition, the detailed trace will be logged as an XML file that you can inspect (or send to us for inspection).
You can by default find this file in %systemdrive%inetpublogsFailedReqLogFilesW3SVC<ID> folder.
If you double-click this file, it will open with the provided XSL stylesheet that shows the trace events. In Longhorn Server, this stylesheet has gotten a major overhaul to highlight the important information better – for more information, see this: http://blogs.iis.net/bills/archive/2006/10/19/Making-Failed-Request-Tracing-More-Approachable.aspx. You can download the new stylesheet and use it today for your Vista machine.
The Failed Request Tracing log provides verbose execution information for the request, that can be used in a number of ways to further diagnose more complex problems that may result from the operation of more than one module. For example, if a url rewriter module changes a url in the request, which later leads to the static file handler failing to find the file, the SetUrl event can provide the needed information. The log also provides such key info as the times taken by each module to execute, the outcome of each of the built-in module’s operation (often including the reason why something didn’t work), and any times when a module fails a request by setting an error response status code.
Finally, one of the main strengths of Failed Request Tracing is that you do not have to be the client to receive the error information. As an administrator, you can configure it to monitor for errors and log the forensic trace when they occur, allowing you to just leave the feature on in production. Think of it as request logs on steroids. To learn more about Failed Request Tracing, see http://www.iis.net/articles/view.aspx/IIS7/Managing-IIS7/Diagnostics-in-IIS7/Using-Failed-Request-Tracing/Troubleshooting-Failed-Requests-using-Tracing-in-I.
I will post more specific strategies on how to troubleshoot with Failed Request Tracing logs in a future post. In the meantime, you should now be a lot more prepared to deal with errors when they occur, and resolve them before you type that first forum post. And if you do make a post (which you are welcome to do), you’ll be able to provide us with the key information to help you solve your problem.
Thanks,
Mike
Свой сайт /
Веб-справка
Аннотация
При обращении пользователей к серверу, на котором запущены информационные службы интернета (Internet Information Services, IIS), по протоколу HTTP или FTP (File Transfer Protocol), сервер возвращает число, показывающее состояние выполнения запроса. Данное число называется кодом состояния и сохраняется в журнале служб IIS, а также может отображаться веб-обозревателем или клиентом FTP. Код состояния показывает, выполнен ли запрос, а также может сообщать о причинах сбоя при выполнении запроса.
Дополнительная информация
Местонахождение файла журнала
По умолчанию файлы журналов служб IIS находятся в папке %WIN DIRSystem32 Logfiles. Данная папка содержит отдельные подкаталоги для каждого узла WWW (World Wide Web) и FTP. По умолчанию новый файл журнала создается ежедневно. Имя данного файла формируется, исходя из текущей даты (например exГГММДД.log).
HTTP
1xx — Информационные коды
Перечисленные ниже коды состояния представляют собой предварительные ответы. Перед получением окончательного ответа клиент может получить один или несколько ответов с кодами состояния 1xx.
- 100 — Следует продолжать работу.
- 101 — Смена протоколов.
2xx — Запрос принят
Нижеперечисленные коды показывают, что сервер успешно принял запрос клиента.
- 200 — ОК. Запрос выполнен успешно.
- 201 — Создан ресурс.
- 202 — Запрос принят.
- 203 — Неавторизованные сведения.
- 204 — Содержимое отсутствует.
- 205 — Сброс содержимого.
- 206 — Частичный ответ.
3xx — Перенаправление
Данные коды показывают, что для выполнения запроса необходимо, чтобы в еб-обозреватель клиента выполнил дополнительные действия. Например, может потребоваться, чтобы веб-обозреватель запросил с сервера другую страницу или повторил запрос, используя прокси-сервер.
- 302 — Объект перемещен.
- 304 — Объект не изменялся.
- 307 — Временное перенаправление.
4xx — Ошибка на стороне клиента
Данные коды показывают, что по вине клиента возникла ошибка. Например, клиент мог запросить отсутствующую страницу или не предоставить сведения для проверки подлинности.
- 400 — Неверный запрос.
- 401 — Отсутствуют необходимые права доступа. Если возникает ошибка с кодом 401, то службы IIS возвращают расширенный код, указывающий причину ошибки. Это коды отображаются на экране веб-обозревателя, но не регистрируются в журнале служб IIS.
- 401.1 — Вход в систему не выполнен.
- 401.2 — Вход не выполнен из-за настройки сервера.
- 401.3 — Доступ запрещен таблицей управления доступом (ТУД) к ресурсу.
- 401.4 — Доступ запрещен фильтром.
- 401.5 — Доступ запрещен приложением ISAPI/CGI.
- 401.7 – Доступ запрещен политикой авторизации URL веб-сервера. Данный код поддерживается только службами IIS 6.0.
- 403 — Запрет доступа. Если возникает ошибка с кодом 403, то службы IIS возвращают расширенный код, указывающий причину ошибки.
- 403.1 — Нет доступа на выполнение.
- 403.2 — Нет доступа на чтение.
- 403.3 — Нет доступа на запись.
- 403.4 — Требуется протокол SSL.
- 403.5 — Требуется протокол SSL 128.
- 403.6 — IP-адрес отклонен.
- 403.7 — Требуется сертификат для клиента.
- 403.8 — Отказ в доступе к узлу.
- 403.9 — Подключено слишком много пользователей.
- 403.10 — Недопусти мая конфигурация.
- 403.11 — Необходим другой пароль.
- 403.12 — Отказ доступа от программы сопоставления.
- 403.13 — Клиентский сертификат отозван.
- 403.14 — Просмотр каталога запрещен.
- 403.15 — Достигнуто максимальное число разрешенных одновременных подключений.
- 403.16 — Клиентский сертификат недействителен или не вызывает доверия.
- 403.17 — Срок действия клиентского сертификата уже истек или еще не начался.
- 403.18 — Не удается выполнить запрошенный адрес URL в текущем пуле приложения. Данный код поддерживается только с лужбами IIS 6.0.
- 403.19 — Не возможно выполнять прило жения CGI для этого клиента в данном пуле приложений. Данный код поддерживается только службами IIS 6.0.
- 403,20 — Вход систему с помощью служб Passport не выполнен. Данный код поддерживается только службами IIS 6.0.
- 404 — Объект не найден.
- 404.0 — (отсутствует) – Файл или каталог не найден.
- 404.1 — Веб-узел не доступен по запрошенному порту.
- 404.2 — Запрос отклонен политикой закрытия расширений веб-служб.
- 404.3 — Запрос отклонен политикой сопоставления MIME.
- 405 — Для доступа к странице используется недопустимый метод HTTP (недопустимый метод).
- 406 — Веб-обозреватель клиента на поддерживает тип MIME запрошенной страницы.
- 407 — Требуется проверка подлинности через прокси-сервер.
- 412 — Отказ после проверки предварительного условия.
- 413 – Размер запроса слишком велик.
- 414 — Слишком длинный запрос URI.
- 415 – Неподдерживаемый тип носителя.
- 416 – Значение за пределами диапазона.
- 417 — Ошибка при выполнении.
- 423 – Ошибка блокировки.
5xx — Ошибки сервера
Данные к оды показывают, что сервер не может выполнить запрос, поскольку при выполнении возникла ошибка.
- 500 — Внутренняя ошибка сервера.
- 500.12 — Приложение в процессе перезапуска.
- 500.13 — Сервер перегружен.
- 500.15 — Запросы на файл Global.asa недопустимы.
- 500.16 – Учетные данные не позволяют выполнить проверку подлинности при подключении к адресу UNC. Данный код поддерживается только службами IIS 6.0.
- 500.18 – Не удается открыть хранилище данных авторизации URL. Данный код поддерживается только службами IIS 6.0.
- 500.100 — Внутренняя ошибка ASP.
- 501 — Значения, указанные в заголовке, требуют нереализованную возможность.
- 502 — Выполняя роль шлюза или прокси, веб-сервер получил ошибочный ответ.
- 502.1 — Превышен интервал ожидания ответа от приложения CGI.
- 502.2 — Ошибка в приложении CGI.
- 503 — Служба недоступна. Данный код поддерживается только службами IIS 6.0.
- 504 — Превышен интервал ожидания ответа от шлюза.
- 505 — Неподдерживаемая версия HTTP.
Основные коды состояния HTTP и их описание
- 200 — Запрос выполнен успешно. Данный код показывает, что сервер IIS успешно обработал запрос.
- 304 — Объект не изменялся. Клиент запросил документ, который имеется в кэше клиента и не изменялся после кэширования. Вместо загрузки документа с сервера клиент использует кэшированную копию данного документа.
- 401.1 — Вход в систему не выполнен. При входе в системе произошел сбой (как правило, вследствие указания ошибочного имени пользователя или пароля).
- 401.3 — Доступ запрещен списком управления доступом (ACL) к ресурсу. Появление данного кода свидетельствует о проблеме с разрешениями NTFS. Эта ошибка может возникать, даже если для запрашиваемого файла разрешения установлены правильно. Например, данная ошибка появляется, если для учетной записи IUSR отсутствуют права доступа к папке C:WinntSystem32Inetsrv. Дополнительные сведения об устранении данной ошибки см. в следующей статье базы знаний Microsoft:
187506 Разрешения NTFS и права пользователей, необходимые для работы сервера IIS 4.0 - 403.1 — Нет доступа на выполнение. Как правило, данная ошибка возникает по следующим причинам.
- Отсутствует право на выполнение. Например, данная ошибка может возникать при обращении к странице ASP, находящейся в папке, для которой отсутствуют разрешения на выполнение, или при запуске сценария CGI из папки, для которой установлены разрешения «Только сценарии». Чтобы добавить право выполнения, в соответствующей консоли MMC щелкните нужную папку правой кнопкой мыши, выберите пункт Свойства, перейдите на вкладку Каталог и убедитесь, что для требуемых объектов разрешения Разрешен запуск установлены должным образом.
Используемый метод (например GET или POST) отсутствует в сопоставлении сценариев для требуемого типа файлов. Чтобы проверить, присутствует ли требуемый метод, в соответствующей консоли MMC щелкните нужную папку правой кнопкой мыши, выберите пункт Свойства, перейдите на вкладку Каталог, щелкните команду Конфигурация и убедитесь, ч то в сопоставлении сценариев для требуемого типа файлов разрешено использование соответствующего метода. - 403.2 — Нет доступа на чтение. Убедитесь, что в конфигурации служб IIS разрешено чтение из данной папки. Кроме того, если используется документ по умолчанию, убедитесь, что данный документ существует. Дополнительные сведения об устранении данной проблемы см. в следующей статье базы знаний Microsoft:
247677 Появление сообщения об ошибке «403.2 Запрет доступа. Нет доступа на чтение.» - 403.3 — Нет доступа на запись. Убедитесь, что существующие разрешения IIS и разрешения NTFS позволяют выполнять запись в нужную папку. Дополнительные сведения об устранении данной проблемы см. в следующей статье базы знаний Ма й крософт:
248072 Появление сообщения об ошибке «403.3 Запрет доступа. Нет доступа на запись.» - 403.4 — Требуется протокол SSL. Отключите параметр Требует ся безопасный канал или используйте для доступа к данной странице протокол HTTPS, а не HTTP. Если эта ошибка появляется при обращении к веб-узлу, для которого не установлен сертификат, обратитесь к следующей статье базы знаний Microsoft:
224389 Появление сообщений об ошибках 403, 403.4, 403.5 «Запрет доступа. Требуется протокол SSL.» - 403.5 — Требуется протокол SSL 128. Отключите параметр Требуется 12 8 -и разрядное шифрование или используйте для просмотра данной страницы веб-обозреватель, поддерживающий 128-разрядное шифрование. Если эта ошибка появляется при обращении к веб-узлу, для которого не установлен сертификат, обратитесь к следующей статье базы знаний Microsoft: 224389 Появление сообщений об ошибках 403, 403.4, 403.5 «Запрет доступа. Требуется протокол SSL.»
- 403.6 — IP-адрес отклонен. Конфигурация веб-сервера запрещает доступ с данного IP-адреса. Дополнительные сведения об устранении данной проблемы см. в следующей статье базы знаний Microsoft:
248043 При подключении к веб-серверу появляется сообщение об ошибке: «Ошибка HTTP 403.6 — Запрет доступа: IP-адрес отклонен» - 403.7 — Требуется сертификат для клиента. Конфигурация веб-сервера требует наличие сертификата для выполнения проверки подлинности клиента, однако сертификат для клиента не установлен. Дополнительные сведения см. в следующих статьях базы знаний Майкрософт.
190004 Появление сообщения об ошибках 403.7 или «Не удается установить соединение с сервером»
186812 PRB: Появление сообщения об ошибке «403.7 Запрет доступа. Требуется сертификат для клиента.» - 403.8 — Отказ в доступе к узлу. Существующие ограничения на доменное имя запрещают доступ к веб-узлу из текущего домена. Дополнительные сведения об устранении данной проблемы см. в следующей статье базы знаний Microsoft:
248032 Появление сообщения об ошибке «403.8 Запрет доступа. Отказ в доступе к узлу.» - 403.9 — Подключено слишком много пользователей. Число пользователей, подключенных к веб-узлу, превысило максимально допустимое число подключений, указанное в конфигурации. Дополнительные сведения об изменении данного значения см. в следующей с тать е базы знаний Майк ро софт:
248074 Ошибка HTTP 403.9 — Запрет доступа: подключено слишком много пользователей
Примечание. Microsoft Windows 2000 Professional и Microsoft Windows XP Professional допускают одновременное подключение к службам IIS десяти пользователей. Это значение изменить нельзя. - 403.12 — Отказ доступа от программы сопоставления. Для доступа к запрошенной странице необходим сертификат клиента, однако пользователь, сопоставленный используемому клиентскому сертификату, не имеет прав доступа к данному файлу. Дополнительные сведения см. в следующей статье базы знаний Microsoft:
248075 Появление сообщения об ошибке «403.12 Запрет доступа. Отказ до с тупа от программы сопоставления.» - 404 — Объект не найден. Данная ошибка может возникать, если запрошенный файл был удален или перемещен. Кроме того, указанное сообщение об ошибке появляется, если после установки средства URLScan был ограничен доступ к файлам с запрошенным расширением. В этом случае в файле журнала для данного запроса будет добавлена строка «Rejected by URLScan».
- 500 — Внутренняя ошибка сервера. Данное сообщение об ошибке может появляться вследствие различных причин. Дополнительные сведения о причинах подобных ошибок могут помещаться в журнал событий. Кроме того, для получения полного описания ошибки можно отключить вывод подробных сообщений об ошибках HTTP. Дополнительные сведения об отключении вывода подробных сообщений об ошибках HTTP см. в следующей статье базы знаний Microsoft:
294 807 Отключение параметра «Выводить подробные сообщения об ошибках http» в обозревателях Internet Explorer 5.x и 6.x на стороне сервера - 500.12 — Приложение в процессе перезапуска. Данное сообщение появляется при попытке загрузить страницу ASP в то время, когда сервер IIS перезапускает приложение. После обновления страницы данное сообщение должно исчезнуть. Если после обновления страницы указанное сообщение остается, то это может быть вызвано работой антивирусной программы, которая проверяет файл Global.asa. Дополнительные сведения см. в следующей статье базы знаний Microsoft:
248013 Сообщение «Ошибка HTTP 500-12 Перезапуск приложения» при подключении к Microsoft Internet Information Services 5. 0 - 500-100.ASP — Внутренняя ошибка ASP. Данное сообщение об ошибке появляется при загрузке страницы ASP, содержащей ошибки. Чтобы получить более полную информацию о данной ошибке, отключите вывод подробных сообщений об ошибках HTTP. По умолчанию данная ошибка может появляться только на веб-узле по умолчанию. Дополнительные сведения о том, как увидеть данную ошибку на веб-узлах, не являющихся узлами по умолчанию, см. в следующей статье базы знаний Microsoft:
261200 Вместо сообщения об ошибке из файла 500-100.asp отображается сообщение об ошибке HTTP с кодом 500 - 502 — Неправильный шлюз. Данное сообщение об ошибке появляется при запуске сценария CGI, не возвращающего соответствующий набор заголовков HTTP.
FTP
1xx — Положительный предварительный ответ
Данный код состояния говорит о том, что выполнение действия началось успешно, но перед переходом к новой команде клиент должен дождаться следующего ответа.
- 110 Значение маркера повторного запуска.
- 120 Служба будет готова через ххх минут.
- 125 Соединение для передачи данных уже уст ановл ено; передача данных начата.
- 150 Состояние файла проверено. Сервер готов к установке соединения для передачи данных.
2xx — Оповещение о выполнении команды
Действие завершилось успешно. Клиент может выполнять следующую команду.
- 200 Команда выполнена успешно.
- 202 Команда не реализована. На данном узле команда не требуется.
- 211 Состояние системы или справка по системе.
- 212 Состояние каталога.
- 213 Состояние файла.
- 214 Справочное сообщение.
- 215 ИМЯ тип системы, где ИМЯ — официальное имя системы в соответствии с документом о присвоении номеров.
- 220 Система готова обслуживать нового пользователя.
- 221 Служба разрывает управляющее соединение. Если необходимо, будет произведен выход из системы.
- 225 Соединение для передачи данных установлено; передача не выполняется.
- 226 Соединение для передачи данных разрывается. Требуемое действие выполнено (например пере дача или прекращение передачи файла).
- 227 Выполняется вход в пассивный режим (h1,h2,h3,h4,p1,p2).
- 230 Пользователь вошел в систему. Производится обработка.
- 250 Требуемое действие завершено успешно.
- 257 Создана папка «ПУТЬ».
3xx — Положительные промежуточные ответы
Данные коды состояния говорят о том, что команда выполнена успешно, но для завершения выполнения запроса клиент должен передать серверу дополнительные сведения.
- 331 Имя пользователя получено. Необходимо ввести пароль.
- 332 Необходима учетная запись для входа в систему.
- 350 Для выполнения запрашиваемого действия требуются дополнительные данные.
4xx — Промежуточные отрицательные ответы
При выполнении команды возникла временная ошибка. Если клиент повторит команду, она может выполниться успешно.
- 421 Служба недоступна. Управляющее соединение разрывается. Данное сообщение может отправляться в ответ на какую-либо команду, если служба должна завершить работу.
- 425 Не удается установить соединение для передачи данных.
- 426 Соединение разорвано; передача прекращена.
- 450 Требуемое действие не выполнено. Файл недоступен (например, файл может быть занят).
- 451 Выполнение требуемого действия прервано: при выполнении возникла ошибка.
- 452 Требуемое действие не выполнено. Системе не хватает места на диске.
5xx — Окончательные отрицательные ответы
При выполнении команды возникла ошибка. Данная ошибка носит постоянный характер. Если клиент повторит команду, при ее выполнении возникнет такая же ошибка.
- 500 Синтаксическая ошибка. Команда не распознана. Одной из причин возникновения этой ошибки является использование слишком длинных команд.
- 501 Синтаксическая ошибка в аргументах или параметрах.
- 502 Команда не реализована.
- 503 Ошибочная последовательность команд.
- 504 Для данного параметра команда не реализована.
- 530 Не выполнен вход в систему.
- 532 Необходима учетная запись для сохранения файлов.
- 550 Требуемое действие не выполнено. Файл недоступен (например, файл не найден или нет доступа к файлу).
- 551 Выполнение требуемого действия прервано. Неизвестный тип страницы.
- 552 Выполнение требуемого действия прервано. Превышен максимально допустимый объем места на диске (в текущей папке или в наборе данных).
- 553 Требуемое действие не выполнено. Недопустимое имя файла.
Основные коды состояния FTP и их описание
- 150 — Протокол FTP использует два порта: порт 21 для передачи команд и порт 20 для передачи данных. Код состояния 150 показывает, что сервер собирается установить новое соединение на порту 20 для передачи данных.
- 226 — Команда устанавливает подключение к порту 20, чтобы выполнить какие-либо действия (например передать файл). Данное действие было завершено успешно. Соединение разорвано.
- 230 — Сообщение с этим кодом появляется после отправки клиентом правильного пароля. Данный код состояния показывает, что пользователь вошел в систему.
- 331 — Сообщение с этим кодом появляется после отправки клиентом имени пользователя. Это сообщение появляется независимо от того, присутствует ли в системе указанное имя пользователя.
- 426 — Команда устанавливает подключение к порту 20, чтобы выполнить какие-либо действия, однако выполнение действия было отменено и соединение было разорвано.
- 530 — Данный код состояния показывает, что пользователь не может войти в систему, поскольку введена ошибочная комбинация имени пользователя и пароля. Если для входа в систему используется учетная запись пользователя, то данное сообщение может появляться, если имя пользователя или пароль введены неправильно или если в систем у могут входить только анонимные пользователи. Если для входа в систему используется анонимная учетная запись, то данное сообщение может появляться, если сервер IIS не поддерживает вход анонимных пользователей.
- 550 — Команда не выполнена, поскольку требуемый файл недоступен. Данное сообщение может появляться при попытке получить отсутствующий файл с помощью команды GET, при использовании команды PUT для сохранения файла в папке, для которой отсутствует право записи, а также в некоторых других случаях.