Continuing from last week’s discussion of HTTP/304 responses, today we’ll cover three more scenarios where Fiddler users might find that the response body sent by the server isn’t what they expected.
The following screenshot shows three Web Sessions, each of which returned a different result status code in the HTTP/2xx range:
The HEAD Request Method
The first request returned a HTTP/200, but you’ll notice that the server didn’t send any bytes in the body. If you examine the headers using the Inspectors tab, you will notice that the client used the HEAD request method. The HEAD method allows the client to query the server for the headers for a given resource without actually downloading the resource itself. The server is expected to return the same headers as it would have if the client had issued a request using the GET method, simply omitting the body from the response.
In this case, you can see that the request would have returned a body that is 6623 bytes long if the client had used a GET instead of a HEAD. The client also learns that the resource at this URL is of type text/html and that it uses the UTF-8 character set. Clients may use a HEAD request to gather information when determining how to handle a given resource. For instance, Internet Explorer will send a HEAD request for the SRC specified by an OBJECT element if that element lacks a TYPE parameter. Internet Explorer can then determine what type of object to instantiate using the Content-Type header on the response.
The second session in the Web Sessions list returned a HTTP/204 response. As you can see in the Headers, the response has no body, and the status code description is “No Content”:
Now, you might ask yourself “Why doesn’t the server just send a HTTP/200 response with a 0-byte body?”
In many scenarios where there is no body to return, the two response codes are effectively identical, but there’s one case when a HTTP/204 behaves differently. The behavior changes in the event that a user is navigating a browser window or an frame/iframe.
- When navigating to a URL that returns HTTP/200 with a 0-byte body, the frame or browser will show a blank document (e.g. all white). The URL of the page or frame shows the new URL.
- If the server instead returns a HTTP/204 response, the frame or body remains unchanged from whatever it contained previously—it’s as if the navigation never happened at all. The URL of the page or frame remains unchanged.
The very uncommon HTTP/205 response code behaves as a HTTP/204 does, except that, in addition to staying on the same document, the client is expected to clear any HTML Forms that appear within that current document.
The third and final session in the Web Sessions list returned a HTTP/206 “Partial Content” response. Such responses are returned when the client indicates that it only requires a part of the resource at the target URL. This situation often arises when the client is resuming an incomplete download, when the client is loading embedded data within a large binary file (common when loading videos or PDF files), or when the client is trying to implement its own form of bandwidth throttling.
You can identify partial content requests by the Range request header. The value of this header specifies which portion of the response body that the client needs:
In this request, the client informs the server that it needs bytes 172,032 to 13,325,503 of this video file.
In most cases, the client also sends headers that identify the specific version of the resource that the server is expected to use. In this case, the client sends the ETag it received with the portion of the file (bytes 0 to 172032) that it already had. This information is sent in the If-Match header. The client also sends the first response’s Last-Modified value using the If-Unmodified-Since request header.
If the server finds that its version of the resource is different than that demanded by the client, it will return a HTTP/412 Precondition Failed response. If the client sent its ETag using an If-Range header instead of the If-Match, the server would instead return the full response body if the client’s ETag didn’t match. Using If-Range saves one network request in the event that the client needs the complete file.
The server’s response headers specify which portion of the file was sent in the Content-Range header, and the length of that portion in the Content-Length header:
You might have noticed the Accept-Ranges header in this response—the server sends this header on every response so that the client knows ahead of time that it is permitted to make Range requests for specific bytes.
When you are using Fiddler and you encounter a HTTP/206 response, but you’d prefer the full file (e.g. because you plan to export a video file to disk), you can follow the same steps we covered last week. Simply select the session in the Web Sessions list and either press the U key, or hold the Control key and click the Replay button in Fiddler’s toolbar.