HTTP Redirects

Each HTTP response produced by a web site contains status code. Browser uses that code to interpret the meaning of the response. Basically there can be three different cases:

  1. The request has been processed successfully by the server and the response body contains the requested resource (web page, image, etc.).
  2. An error has occurred.
  3. Server redirects the request to a new URL.

In the latter case the response contains a special “Location” header in which the new URL is provided. When browser receives such response, it automatically issues a new request using the specified URL. This way it can be redirected even to a different web site. The whole thing is done automatically, so the user does not see the process in the browser window. When the response to the new request is received, it is displayed by the browser as if it was the original one. Only the URL in the address bar is changed.

In fact, there can appear several redirects in a row. I mean that the second response can return with the redirect status code again, and so on. However this should end somewhere and usually no more than two redirects are performed.

The status code for redirect is any 3 digit value beginning with “3”, like 301, 302, 303, and so on. It is also usually appended with a status message like “Found” or “Moved Permanently”, however the basic browser action is the same in all cases: it issues a new request with the provided URL.

Why is this needed? There can be several reasons for this. The simplest situation is when the requested resource has really changed its location and now it is available on a different server or at a different address. However, much more frequently redirects are used for the integration between web sites. Let’s see how this is done in practice. The following web page contains a form used to submit messages to the WAPT support: http://www.loadtestingtool.com/support.shtml.

When I fill the above form and click the “Submit” button, it generates the following POST request to the www.backupboutique.com web site:

POST /cgi-bin/send.cgi?to=support@loadtestingtool.com HTTP/1.1

The following parameters are passed inside its body:

get=http://loadtestingtool.com/support.shtml
from=test@test.com
feedback=test+message

The response of that web site is:

HTTP/1.1 302 Found
Location: http://loadtestingtool.com/support.shtml

This means that it has accepted the information passed to it and redirects the browser back to the same web page that issued the request.

What useful facts about redirects can be noted in relation to load testing? First of all, most load testing tools process redirects automatically. This means that when they record tests, they save only the initial request. They do not add to the test the URL to which it was redirected. When the request is replayed, the server returns a new URL and the testing tool issues a new request to that URL automatically. However it is important to understand that actually several requests are performed and several web sites could be involved in the processing of them.

In WAPT you can see the full sequence of redirects for each recorded request. As noted above, in the test only the initial request is used, but for your reference it is possible to view the details of each recorded redirect on the “Response processing” tab. There is a list box in which you can select the exact request and see its details below.

By default WAPT shows the last request in the sequence, which leads to some confusion, if you expect to see the details of the original request here. However such behavior is convenient in a more common situation when you want to take a look at the server response. Note that when you add variables to the response processing and use functions to assign values to them, they always work with the latest response in the redirect sequence, because it contains the real page content shown in by the browser.

After we verify or run the test, we can check how the redirect is shown in the log:

The original request is grayed out and the final redirected one is colored depending on the status code. You can select any of them and see the details in the view below. This works the same way as for any other request.