Increasingly many business applications are being built with web frontends. In order to manage these applications, network managers require both solutions capable of isolating HTTP transaction details and providing analysis, as well as the knowledge to interpret the analysis and successfully resolve issues.
In this article we’ll explore the meaning of critical HTTP status codes, illustrate logical troubleshooting workflows, and how to provide evidence web developers can act upon
HTTP Status Codes
||The server has received the request headers and the client should proceed to send the request body. This confirms communications are running smoothly; look further into the conversation for potential issues.
||Standard response for successful HTTP request. This is what you want to see in web communications.
||This could be indicative of a couple of things. Too many redirections could show some inefficiency internal to the web app design. It may also show some form of load balancing was being used.
||Authentication either failed or was not provided
||Client issue of application making an illegal request. Server is refusing to respond.
||Requested resource was not found. Subsequent requests from client permissible.
||Internal Server Error
||Generic error for when server failed to fulfill a request
||Server was acting as a gateway or proxy, and received invalid response from upstream server
||Server currently unavailable; either overloaded or temporarily down. If server is under high memory pressure, it will temporarily refuse new requests. If this error code persists, server may need additional memory or memory configuration settings may need to be changed.
As you look at web transactions and packets, it’s first important to be familiar with the various response status codes. In the following table, we have outlined some of the more common HTTP status codes and what they mean to the network engineer.
Establish Troubleshooting Workflows
The HTTP status codes not only provide an indication to the network engineer of what might be happening within the application, they can also be valuable to the web application developer for resolving potential issues. But how do you go about isolating potential error codes?
In this example, a user complains that a web application is running slow, but it’s not enough to understand the server took more than 5 seconds to fulfill a user request. We need to drill down to isolate the exact server error and cause of the problem.
We begin by looking at a snapshot of HTTP Requests and Responses. You can see clearly what type of requests occurred during the timeframe represented in the horizontal graph. This is a first step in understanding what type of request and what response times occurred for each request. Over to the right, we see the different HTTP status code responses. Looking at the status codes, you’ll see some of these are errors, most notably the “HTTP 500 = Internal Server Error” for 10.0.38.178. When you see this type of 500 range error, it indicates the server is having trouble processing the request.
Investigating further, this is where it’s important to have both trending and long-term packet capture technologies in place to see how prevalent the problem is and isolate the exact cause. With trending activated, we can see when and how often server errors occurred. Checking the trouble ticket, we see the user complaint was between 9:00 am and 9:40 am. The report showed the frequency of errors, and identified the problem server for this time period.
From within this report we can drill down and mine the packets associated with this server and condition and analyze them for the specific issue. In this case, the process is automated using Observer® Reporting Server and drilling to the GigaStor™ long-term packet capture appliance for analysis
Looking inside the packets, the error was caused by a Failed Session Token. There is a host of other information here that will help the web application designers resolve the issue and eliminate this particular problem from reoccurring.
With a comprehensive understanding of HTTP status codes and a logical troubleshooting workflow, resolving web application errors can be done quickly and allow you to provide actionable information to web developers to effectively solving the problem