Quantcast
Channel: Randy Riness @ SPSCC aggregator
Viewing all articles
Browse latest Browse all 3015

MSDN Blogs: Troubleshooting Azure App Service Apps Using Web Server Logs

$
0
0

Oftentimes, the best way to start troubleshooting a web application is to check the web server logs. Web servers log each request that they process, and by checking the server logs, you can often find out details about why things went wrong. Particularly, you want to pay attention to a couple of different fields in the log file; the HTTP status code and the HTTP sub-status code. In your server logs, these are labeled as sc-status and sc-substatus.

Please keep in mind that requests are not immediately added to your web server logs. It may take a couple of minutes between the time a request is made and the time that it makes it into your server logs.


Note: For information about enabling diagnostic logs and downloading logs in Azure App Service, see Enable Diagnostics Logging for Web Apps in Azure App Service. This documentation is useful for enabling, downloading and analyzing all of the different diagnostic logs mentioned in this post. 

HTTP Status Classes

The first digit of an HTTP status code indicates the class of the status code. You can get a general idea of what a particular entry in your web server logs means by the class. The following outlines the various HTTP status code classes.

  • 1 (Status codes 1xx) – Informational messages indicating that a request was received and is processing.
  • 2 (Status codes 2xx) – A successful request. The web server understood the request and processed it.
  • 3 (Status codes 3xx) – The client (usually a web browser) needs to take additional action in order to complete the request. (This is often a redirection, but not always.)
  • 4 (Status codes 4xx) – An error from the client prevented the request from being processed.
  • 5 (Status codes 5xx) – The request was valid, but a problem at the server prevented the request from succeeding.

Now that you know the various HTTP status classes, let’s look at some of the more common HTTP status codes you might see in a Web App running in Azure App Service. I’ll skip the class 1 and class 2 status codes since they are informational or successful.

Class 3 Status Codes

A class 3 status code means that the client must take additional action in order to complete the request. The following class 3 status codes might appear in your web server logs.

 StatusSub-Status Description
301N/AMoved Permanently – Typically used when a URI changes due to a site redesign and so forth. When a search engine crawler encounters this status, it will usually force an update of the URI for the search engine index as well.
302N/AObject Moved – Used when a redirect is required for purposes of logging a user in, temporarily redirecting a URI, etc.
304N/ANot Modified – Indicates that the URI requested has not been modified since the client last requested it. This will usually mean that the client uses a cached copy of the resource.
307N/ATemporary Redirect – Similar to a 302 redirect, but a 307 redirect does not allow the client to change the HTTP method used to request the resource.

 

Class 4 Status Codes

A class 4 status code means an error from the client prevented the request from being processed. The following class 4 status codes might appear in your web server logs.


Note: There are some cases where you can see a 403 status in the browser, but no 403 events are logged in the HTTP server logs. For example, if your Web App is stopped, you will see a 403 error in the browser telling you the site is stopped, but you won’t see a 403 in the server logs. If your site is disabled due to a quota violation, that will also show a 403 in the browser without a corresponding entry in the server logs. For more information on troubleshooting 403 errors, see the Web Apps support team blog.

           
 StatusSub-Status Description
4000Bad Request – The client sent a request that was unrecognized by the server or that was badly formed and rejected. It is often helpful to review Failed Request Tracing to get more details on any 400 error, regardless of sub-status. A 400 HTTP status means that the client did not send a good request to the server.
4006Invalid Request Body
4007Invalid Content Length
4010Unauthorized – The web app requires an authenticated user and the user was not authenticated. When a 401 occurs, you will typically see a sub-status that will give you more information. Refer to the following sub-status codes.
4011Logon Failure – The request contained credentials but they were not accepted by the authentication provider. This is typically caused by an incorrect username and/or password or a user who doesn’t have permission to access the resource.
4012Logon Config – This is caused by a problem in the authentication settings on the server. In Web Apps, this would likely be returned by an authentication module on the server. Checking Failed Request Tracing logs to see which module set the 401.2 status would be advised.
4013Logon ACL – The user did successfully authenticate, but the user does not have permissions to access the resource. Check to ensure that the user has been given permission. For example, if you are using Azure Active Directory authentication, ensure that the user has been given permission in Azure Active Directory.
4017URL Auth Policy – The user was denied access to the specific URL due to URL Authorization. For more information on this feature, see this. For information on URL authorization with ASP.NET, see this.
401501The request was denied by Dynamic IP Restriction. In this case, the client made too many concurrent requests. (For information on configuring Dynamic IP Restrictions in Web Apps, see this.)
401502The request was denied by Dynamic IP Restriction. In this case, the client exceeded the allowed request rate. (For information on configuring Dynamic IP Restrictions in Web Apps, see this.)
401503The request was denied by IP Restriction because the source IP address is not allowed. (For information on configuring IP Restriction in Web Apps, see this.)
401504The request was denied by IP Restriction because the source host name is not allowed. (For information on configuring IP Restriction in Web Apps, see this.)
4030Forbidden – The request was forbidden for some reason. Without a sub-status code, the best way to dig further would be to use Failed Request Tracing.
4034SSL Required – The request was made without SSL, but the resource is configured to require SSL. Use HTTPS instead of HTTP.
40314Directory Listing Denied – A URI was used that did not specify a document name and no default document is configured. See the Azure documentation on configuring a default document for your Web App.
403501The request was denied by Dynamic IP Restriction. In this case, the client made too many concurrent requests. (For information on configuring Dynamic IP Restrictions in Web Apps, see this.)
403502The request was denied by Dynamic IP Restriction. In this case, the client exceeded the allowed request rate. (For information on configuring Dynamic IP Restrictions in Web Apps, see this.)
403503The request was denied by IP Restriction because the source IP address is not allowed. (For information on configuring IP Restriction in Web Apps, see this.)
403504The request was denied by IP Restriction because the source host name is not allowed. (For information on configuring IP Restriction in Web Apps, see this.)
4040Not Found – A request was made for a resource that was not found on the server. This is typically a request to a non-existent file.
4045URL Sequence Denied – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
4046Verb Denied – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
4047File Extension Denied – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
4048Hidden Segment – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
40410Request Header Too Long – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
40411URL Double Escaped – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
40412URL Has High Bit Characters – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
40413Content Length Too Large – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
40414URL Too Long – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
40415Query String Too Long – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
40418Query String Sequence Denied – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
40419Denied by Filtering Rule – The request was denied due to the configuration of Request Filtering. See the documentation on Request Filtering for more information. 
404501The request was denied by Dynamic IP Restriction. In this case, the client made too many concurrent requests. (For information on configuring Dynamic IP Restrictions in Web Apps, see this.)
404502The request was denied by Dynamic IP Restriction. In this case, the client exceeded the allowed request rate. (For information on configuring Dynamic IP Restrictions in Web Apps, see this.)
404503The request was denied by IP Restriction because the source IP address is not allowed. (For information on configuring IP Restriction in Web Apps, see this.)
404504The request was denied by IP Restriction because the source host name is not allowed. (For information on configuring IP Restriction in Web Apps, see this.)

 

Class 5 Status Codes

A class 5 status code means the request was valid, but a problem at the server prevented it from completing. The following class 5 status codes might appear in your web server logs.

 StatusSub-Status Description
5000Internal Server Error – Typically caused by an error in server-side code. If using Internet Explorer, it is often helpful to turn off Friendly HTTP Error Messages to get more information. You may also want to troubleshoot such errors with Visual Studio. See Troubleshoot a Web App in Azure App Service Using Visual Studio for more information.
50050URL Rewrite Error – Error in inbound rule or a configuration error in URL Rewrite. For more information, see the documentation on URL Rewrite.
50051URL Rewrite Error – Global configuration or global rules execution error occurred. For more information, see the documentation on URL Rewrite.
50052URL Rewrite Error – Outbound rule error occurred. For more information, see the documentation on URL Rewrite.
50053URL Rewrite Error – Outbound rule error occurred. The rule is configured to execute before outbound cache gets updated. For more information, see the documentation on URL Rewrite.
500121The request was timed out by Azure App Service. Azure App Service will timeout any request that executes for 230 seconds without sending a response. If you encounter this, the solution is to troubleshoot the slow request.
502N/AServer received an invalid response while acting as a gateway or proxy. This status may be shown in a browser, but you may not see an entry in your logs. This actually may be caused by your application crashing when a request is received. You can often find details by parsing the eventlog.xml file. To troubleshoot this, see our documentation on troubleshooting these issues.
5030Server Unavailable – This is often caused by an application issue, often a crash in your application. Your best bet for tracking that down is to follow our troubleshooting steps on these errors.

 

I hope this information helps you to troubleshoot HTTP status codes that you might see in your Azure App Service application.


Viewing all articles
Browse latest Browse all 3015

Trending Articles