Understanding http/304 Response

Original: Http://www.telerik.com/automated-testing-tools/blog/eric-lawrence/12-11-06/understanding-http-304-responses.aspx

Users who are just beginning to use fiddler are often puzzled by the http/304 response in the Fiddler Network session (Web Sessions) List :

If the client sends a conditional validation (Conditional Validation) Request , the Web server may return a http/304 response, which indicates that the cache of the requested resource in the client is still valid. This means that the resource has not been modified since it was last cached. Conditional requests can be used to ensure that the client's resources are up-to-date while avoiding the performance issues associated with requesting full resources each time.

Identify a condition request

A conditional request is sent when the client caches the target resource but is not sure whether the cache resource is the latest version. In Fiddler, you can find the relevant request header in the Headers Inspector , so that you can tell if a request is a conditional request.

When a conditional request is made, the client provides a if-modified-since request header to the server with a value of the date value in the last-modified response header that was last returned by the server, and a The If-none-match request Header value is the value of the ETag response header that the server last returned:

The server reads the values in both request headers to determine if the client caches the resources are up-to-date, and if so, the server returns a http/304 not Modified response, but no response body. After the client receives a 304 response, The corresponding resource is read from the cache.

Alternatively, if the server considers that the client cache resource has expired, the server returns the http/200 OK response, which is the most current content of the resource. After the client receives a 200 response, it overwrites the old cache resource with the new response body.

A conditional request can be sent only if the client has cached the corresponding resource and the resource's response header contains a last-modified or ETag . If none of the two headers exist, you must unconditionally ( Unconditionally) requests the resource, the server must also return the full resource data.

Why use conditional requests

When a user accesses a Web page, the conditional request accelerates the page's opening time (because it saves time to transmit the entire response body), but there is still network latency because the browser has to generate a conditional request for each resource and wait until the server returns a http/304 response. To read the cache to display the Web page. Ideally, the server specifies the Cache-control or expires directive on the response so that the client can know how long the resource is available, and can skip the conditional request step and directly use the resources in the cache. But, Even if the server provides this information, you still need to use conditional requests in the following situations:

• After the expiration time specified by the server is exceeded
• If the user performs a refresh operation

In the picture given in the previous section, a Pragma:no-cacheis included in the request header. This is because the user has refreshed the Web page with F5 . If the user presses the ctrl-f5 (sometimes called a "strong brush-hard Refresh "), you will find that the browser omits the if-modified-since and If-none-match request headers, which is the unconditional request for each resource in the page.

Avoid conditional requests

In general, caching is a good thing. If you want to improve your site's access speed, caching must be considered. However, when debugging, it is sometimes necessary to block the cache to ensure that the resources you access are up-to-date.

You may have a question: "How can I let fiddler not return 304 and return a http/200 response with a response body without changing the content of the site?"

You can select a session in the network session (Web Sessions) List in Fiddler that responds to http/304, and then press the U key. Fiddler will be re-sent unconditionally ( Unconditionally reissue) this request. Then use the compare command to compare the difference between the two requests, the comparison results are as follows, it can be learned that the Fiddler is to omit the conditional request header to implement a cache-free request :

If you want to block the http/304 response globally, you can do this by first clearing the browser's cache, using the Clear Cache button on the Fiddler toolbar (only the Internet Explorer cache can be cleared), or by pressing CTRL on the browser +shift+delete (supported by all browsers). After clearing the browser's cache, go back to fiddler and select the Rules > Performance > Disable Caching option in the menu. Then fiddler: Deletes all requests in the condition request with the same request header and all responses in response to the cache time-related response header. In addition, the Pragma:no-cache request header is added to each request, and each response is added Cache-control:no-cache The response header to prevent the browser from caching these resources.

Understanding http/304 Response