Troubleshooting Azure App Service Apps Using Web Server Logs




First published on MSDN on Jun 22, 2016




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.






























Status



Sub-Status



Description


301

N/A

Moved 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.

302

N/A

Object Moved – Used when a redirect is required for purposes of logging a user in, temporarily redirecting a URI, etc.

304

N/A

Not 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.

307

N/A

Temporary 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

.




























































































































































































Status



Sub-Status



Description


400

0

Bad 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.

400

6

Invalid Request Body

400

7

Invalid Content Length

401

0

Unauthorized – 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.

401

1

Logon 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.

401

2

Logon 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.

401

3

Logon 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.

401

7

URL 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

.

401

501

The 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

.)

401

502

The 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

.)

401

503

The 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

.)

401

504

The 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

.)

403

0

Forbidden – 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

.

403

4

SSL Required – The request was made without SSL, but the resource is configured to require SSL. Use HTTPS instead of HTTP.

403

14

Directory 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.

403

501

The 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

.)

403

502

The 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

.)

403

503

The 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

.)

403

504

The 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

.)

404

0

Not 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.

404

5

URL Sequence Denied – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

6

Verb Denied – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

7

File Extension Denied – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

8

Hidden Segment – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

10

Request Header Too Long – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

11

URL Double Escaped – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

12

URL Has High Bit Characters – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

13

Content Length Too Large – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

14

URL Too Long – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

15

Query String Too Long – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

18

Query String Sequence Denied – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

19

Denied by Filtering Rule – The request was denied due to the configuration of Request Filtering. See the

documentation on Request Filtering

for more information.

404

501

The 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

.)

404

502

The 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

.)

404

503

The 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

.)

404

504

The 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.


















































Status



Sub-Status



Description


500

0

Internal 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.

500

50

URL Rewrite Error – Error in inbound rule or a configuration error in URL Rewrite. For more information, see the

documentation on URL Rewrite

.

500

51

URL Rewrite Error – Global configuration or global rules execution error occurred. For more information, see the

documentation on URL Rewrite

.

500

52

URL Rewrite Error – Outbound rule error occurred. For more information, see the

documentation on URL Rewrite

.

500

53

URL 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

.

500

121

The 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

.

502

N/A

Server 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

.

503

0

Server 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.