: Headers to prevent 304/If-modified-since/HEAD requests What headers should I be sending to outright stop all requests to the server after the content has been cached? We have a very high latency
What headers should I be sending to outright stop all requests to the server after the content has been cached?
We have a very high latency server (Sigh, VMWare) so even sending a HEAD request to the server takes +40ms.
Currently these are the headers being sent/received;
First request
Client sends;
GET dugong:8080/Rvi24mYJkxFRGNzq73PPvgWGh1j/IMG_2071.jpg HTTP/1.1
Host: dugong:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Pragma: no-cache, no-cache, no-cache
Cache-Control: no-cache, no-cache, no-cache
Server responds;
HTTP/1.1 200 OK
Server: nginx/1.0.11
Date: Wed, 01 Feb 2012 14:51:51 GMT
Content-Type: text/plain
Vary: Accept-Encoding
Last-Modified: Tue, 31 Jan 2012 10:45:11 GMT
Content-Length: 14
Expires: Thu, 31 Jan 2013 14:51:51 GMT
Cache-Control: max-age=31536000
So it sends a Cache-Control and Expires header set to 365 days in the future. Unfortunately on the second refresh it requests the object again with an If-Modified-Since header.
Second Request
GET dugong:8080/Rvi24mYJkxFRGNzq73PPvgWGh1j/IMG_2071.jpg HTTP/1.1
Host: dugong:8080
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip, deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
If-Modified-Since: Tue, 31 Jan 2012 10:45:11 GMT
Cache-Control: max-age=0
Response;
HTTP/1.1 304 Not Modified
Server: nginx/1.0.11
Date: Wed, 01 Feb 2012 14:58:00 GMT
Vary: Accept-Encoding
Expires: Thu, 31 Jan 2013 14:58:00 GMT
Cache-Control: max-age=31536000
Unfortunately due to silly outdated proxy software we can't use Keep-Alive, or put any other servers/proxys in front of the application. We also can't improve the performance of the server and reduce the network latency. I've been trying to figure out what headers we can send to get rid of the 301 requests. I've tried using ETags but that makes no difference, it still sends a If-modified-since header. I've also tried removing the Last-Modified header but that just causes a standard GET request with no caching (Checked the logs, server still receiving requests).
Clients are a mix of Firefox (mostly), IE 7, 8 and (some) 9, Chrome and Safari but this behavior seems to be appearing in all browsers tested.
TL;DR;
Terrible network, what headers should I send to tell clients to never ever ever send If-modified-since requests to the server to validate their cache, and keep content cached until the Expires header is met?
I'm probably missing something obvious but everything I try seems to yield the same results.
We have an NGINX server sat in front of our application server so I can add/remove any headers as I please. Our proxy doesn't support Keep-Alive and theirs no way to improve the attrocious network performance. Due to terrible software design the web app loads +100 resources on each page load (Yeah, enterprise software sucks) with a latency of ~40-50ms per object.
More posts by @Pierce454
4 Comments
Sorted by latest first Latest Oldest Best
What you want is the immutable keyword in your Cache-Control line.
Example for php:
header('Cache-Control: public, max-age=80000, immutable');
Source: code.facebook.com/posts/557147474482256/this-browser-tweak-saved-60-of-requests-to-facebook/
A little off-topic but maybe helpful.
Another improvement for your requests of cached content, is to cache in sessionStorage so that you don't need to ask server to validate cache and receive a 304.
Look for example google, open the console and write sessionStorage. You will see that they are caching CSS or DOM with the sessionStorage. ofc, you cannot use that in old IE browsers.
I had the same issue, and the Requests are definitely hitting the server for it to respond with the 304 status - I'm sending the 304 via some C# and for sure it hits the server..
I only had Cache-Control: private set. No max-age and no Expires It operated as expected; hit the server with the If-Modified-Since where I test the value compared to what I expect and deliver 304 w/empty response body - else 200 & full the response body.
Setting Expires header had the desired results, 200 - (from cache) on client & no HTTP requests hit the server.
But.. I found that setting BOTH max-age= & Expires can cause browsers to not send If-Modified-Since header AND not to cache at all if the values don't match.
Something to be aware of if you have caching issues & used the different headers in combination.
You can't really control what headers user agents decide to send to you. If the file in question is in the browser's cache and it decides it need to check for a new version then it will. According to this article, these are the situations browsers will request using If-Modified-Since:
The cached entry has no expiration date and the content is being accessed for the first time in a browser session
The cached entry has an expiration date but it has expired
The user has requested a page update by clicking the Refresh button or pressing F5
So if you are reloading the page to test your caching, it won't work since the browser will re-request the images. Try clicking a link then another link back to the first page. If your users are regularly reloading pages then you may need to rethink your site/app structure to prevent that.
One thing that may help is adding "public" to the cache control header, i.e. Cache-Control: public, max-age=31536000. I also learned recently that an expiry date of more than one year is invalid. Since your expiry date is exactly one year, perhaps lowering that by a few days or weeks would ensure the file stays in browser caches and is not discarded.
Terms of Use Create Support ticket Your support tickets Stock Market News! © vmapp.org2024 All Rights reserved.