HttpWatch: Troubleshooting

Troubleshooting

The easy way to view HTTP!

Troubleshooting HTTP using HttpWatch

The following guide to troubleshooting HTTP using HttpWatch is reproduced, by kind permission of the authors, from section 2.9 of 'Advanced BSP Programming' by Brian McKellar and Thomas Jung.

2.9 Trouble Shooting Examples

Knowing how HTTP works, and having a good HTTP trace tool at hand, allows us to trouble shoot many different types of situations without even looking at the source code. In this section we will look at a few typical problems that we often encounter.

2.9.1 Missing Resource

The “little red cross” is seen often (see Figure 2.14). It is very annoying but actually very simple to at least isolate to specific URL.

Figure 2.14: Trouble Shooting a Missing Resource (click to enlarge)

Looking at the HTTP trace, we see that first a HTTP request is answered with a return code of 200, and the content type set to text/html. This is an HTML page that contains a reference to an image. The next HTTP request attempts to load the image itself, and is answered with a HTTP return code of 404 (not found).

The 404 shows immediately that this is the HTTP request that was not loaded correctly. There are typically two problems that can account for this situation. The first is that the URL itself is not correct. In this case, use the Referer HTTP header from this request to see what HTML page contains the bogus link (always one higher up in the HTTP trace), and start there to investigate further. The other alternative is that the URL is correct, and the server has a problem answering the request for the resource. Paste this requested URL directly into the browser and debug the server side to resolve the issue.

2.9.2 Non Secure Warnings

The warning message “page contains non-secure items” always causes calls for help. This warning message usually indicates that the web site is been accessed via https:// protocol, and that now one of the resources on the page is been requested via the http:// protocol. Let us look at the HTTP trace in Figure 2.15.

Figure 2.15: Trouble Shooting Non Secure Warnings (click to enlarge)

We can see that the last HTML page (type text/html) is loaded with https:// protocol. However, the next HTTP request (with a response of type image/gif) was with http:// protocol. This is the reason for the warning! Using the Referer HTTP header of the image, it is possible to easily cross reference it to the HTML page that requested this image, and contains the URL with the wrong protocol.

For interest, the other reason that we often see for this warning is when <iframe> tags are used on page with the src attribute set. This is a typical technique in HTML to later trigger the <iframe> loading dynamically.

2.9.3 Relative URLs That Become Invalid

The next example is from an application that worked for a long time. Then one day, the same application was not started under its usual URL, but via a short alias. Figure 2.16 shows the “little red cross” and the corresponding HTTP trace.

Figure 2.16: Trouble Shooting Invalid URLs (click to enlarge)

We see already from the first HTTP request, that it is not our usual /sap/bc/bsp path, but a much shorter alias. The next HTTP request for an image is now answered with a HTTP return code of 404, and a quick examination shows that the URL is wrong (the /sap segment is not specified). So already we know that the URL is invalid. Let us look at the last response received for the HTML page.

HTTP/1.1 200 OK
Content-Type: text/html; charset=iso-8859-1
Content-Length: 186
Cache-Control: no-cache
Server: SAP Web Application Server (1.0;640)

<html><body><form method="POST">
<img src="../../../../public/bc/icons/s_B_OKAY.gif">
<input type="submit" value="Hit Me!">
</form></body></html>

We see in the HTTP response that the HTML page is requesting a relative URL ../../../../public/…. This URL on its own looks to be perfectly acceptable. However, from the HTTP trace we know that the URL of the requested HTML page is /book_chapter02(…)/exampleNN.html. Given this absolute URL, plus the relative URL specified, we now can see why the browser constructed the new URL /public/…. Effectively, the relative path stripped all tokens from the original URL until none was left. All other /.. sequences to specify the parent node are ignored, and then the browser starts again with the first token /public from the relative path to build the new URL.

In HTML pages, it is recommended to use absolute paths to public resources. If relative paths are used, then only in the relative-as-child relationship, and now over the parent (/..) path.

2.9.4 Estimating Performance

In this section, we just want to highlight other uses of a HTTP trace tool. Often we are interested in having some performance numbers for a web site. A HTTP trace can already help to get a rough estimate of a web application’s performance.

Figure 2.17: Trouble Shooting Performance of HTTP Requests (click to enlarge)

In Figure 2.17 we can see the number of requests, the size in bytes that each request retrieves from the server, the resources that are loaded, and in subsequent testing, whether these resources are cached or continuously reloaded. For example, three times the same HTML page was loaded and in all three cases 17330 bytes were loaded. However, the first request took 3.8 seconds to complete, where the other two requests were only 1.4 seconds. As the pages rendered the same (sized) HTML output, it looks to be more a case that the initialization of the page the first time took a long time. These measurements are round-trip latency, and reflect the time to transfer data to the server, process the data, and the response back to the server.