I'm setting the Cache-Control and Expires HTTP headers to allow caching of static resources. This works fine as expected on Chrome and Firefox. However, IE11 and Safari make a fresh request for the static resources everytime.
Accept-Ranges:bytes
Cache-Control:max-age=31535999
Content-Length:186824
Content-Type:application/x-font-woff
Date:Thu, 21 Apr 2016 09:54:15 GMT
ETag:W/"186824-1461231024000"
Expires:Fri, 21 Apr 2017 09:54:15 GMT
Last-Modified:Thu, 21 Apr 2016 09:30:24 GMT
Server:Apache-Coyote/1.1
Do I need to set any special headers for IE and Safari? I'm using org.apache.catalina.filters.ExpiresFilter to set the response headers.
Turns out this was because of "Always refresh from server" option turned on by default when IE Developer tools is opened.
Related
Setup
I have a static site served by Nginx. I use Webpack to build the assets with a contenthash in the filename:
index.html
main.723f2b08bd448896ca78.js
main.18a850dffbe46cca9feb.css
When I edit my JavaScript code and redeploy the site, the root directory changes to:
index.html
main.08ddcf9a702a6772ce2d.js # <- new hash
main.18a850dffbe46cca9feb.css
Problem
When I open a new tab in Chrome, type my domain name, and press Enter - in the Network tab, I see that Chrome is still loading the old files:
Name Status Type Initiator Size Time
mydomain.com 200 document Other (disk cache) 4 ms
main.723f2b08bd448896ca78.js 200 script (index) (disk cache) 17 ms
main.18a850dffbe46cca9feb.css 200 stylesheet (index) (disk cache) 13 ms
When I click example.com, the HTML in Response includes the old script:
<script src="/main.723f2b08bd448896ca78.js"></script
Also, the Response Headers on index.html are outdated:
Content-Encoding: gzip
Content-Type: text/html
Date: Thu, 26 Jan 2023 09:21:31 GMT
ETag: W/"63d06108-202"
Last-Modified: Tue, 24 Jan 2023 22:51:52 GMT
X-DNS-Prefetch-Control: off
Furthermore, when I click on main.723f2b08bd448896ca78.js, the Response Headers are also out-of-date:
Accept-Ranges: bytes
Content-Length: 605458
Content-Type: application/javascript
Date: Thu, 26 Jan 2023 09:21:31 GMT
ETag: "63d06108-93d12"
Last-Modified: Tue, 24 Jan 2023 22:51:52 GMT
If I reload the page, Chrome loads the new files correctly. But if I then open a new tab again, type the domain, and press Enter - it still loads the old assets! This leaves me with a hard page reload (Ctrl + Shift + R) which finally resets the cache.
Expectation
When I load my site in Incognito I get the correct files as expected:
Name Status Type Initiator Size Time
mydomain.com 200 document Other 557 B 634 ms
main.08ddcf9a702a6772ce2d.js 200 script (index) 606 kB 1.28 s
main.18a850dffbe46cca9feb.css 200 stylesheet (index) 87.2 kB 497 ms
index.html Response:
<script src="/main.08ddcf9a702a6772ce2d.js"></script
index.html Response Headers:
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/html
Date: Thu, 26 Jan 2023 10:33:44 GMT
ETag: W/"63d249c7-202"
Last-Modified: Thu, 26 Jan 2023 09:37:11 GMT
Transfer-Encoding: chunked
main.08ddcf9a702a6772ce2d.js Response Headers:
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 605595
Content-Type: application/javascript
Date: Thu, 26 Jan 2023 10:33:44 GMT
ETag: "63d249c7-93d9b"
Last-Modified: Thu, 26 Jan 2023 09:37:11 GMT
Question
I don't understand what I'm doing wrong - Nginx is returning new values for Etag and Last-Modified. The contenthash changes between deployments. Yet the JS file is still cached very aggressively. This problem happens to me and other people using the site. In this case, it caused a white screen of death, and I had to tell everyone to do a hard page reload (which is foreign and bewildering to the end users).
Is there a solution for this? I don't mind disk cache but how do I tell Chrome not to use it when the asset file changes? Is this an Nginx misconfiguration?
Thank you.
It's your job to tell the browser how long it can cache a resource. You do so by setting the Cache-Control response header (MDN). If you don't set it, the browser is free to decide for itself how long is appropriate. That seems to be what's happening in your case.
Simply set Cache-Control: no-cache on your index.html response header and this problem will go away. The page will still be cached by the browser, but the browser won't use it without first checking with the server to see if it's still current (that's what the ETag is for).
For your static resources, though, you should set a long cache time, since the whole purpose of versioning file names like that is to allow any given one to be immutable.
I have a web application and two computer, both with win7 and chrome v56.0.2924.76.
and in the app it need several js file. when I request the resources, it response with the same response headers
Cache-Control:max-age=7200, must-revalidate
Connection:Keep-Alive
Content-Encoding:gzip
Content-Language:en-US
Content-Type:application/javascript
Date:Mon, 06 Mar 2017 09:40:11 GMT
Expires:Mon, 06 Mar 2017 11:40:11 GMT
Keep-Alive:timeout=5, max=496
Last-Modified:Wed, 22 Feb 2017 18:47:28 GMT
Transfer-Encoding:chunked
X-Powered-By:Servlet/3.0
in one desktop, everything works fine, and it get all js file from cache, while in another desktop,most are fine while some are still getting from the remote.
the difference is: on the not cached desktop the request has requester header with all detail like Accept/Accept-Encoding/Cookie/etc.
and on the cached desktop have the request header say
Provisional headers are shown
I think since one of them is working, the remote server is fine, the problems is in the chrome side, while they both are the same version, I want to know anything else can I check.
Here is the root cause, "not working one" don't installed the correct certification so that the "not working one"'s https is not secure, and there is a warning before the url say "not secure", and chrome seems not cache the not secured content so the files are not cached, after I installed the correct certification it works fine now.
I'm developing a web site and i have setting up the following structure in production eviroment:
NGINX (listening 443,proxy_pass) -> Varnish (listening 80) -> NGINX (listenig 8080).
So i can serve via https cached content.
The problem is that i have noticed that google crome is not caching locally content served via SSL (Firefox does)
When i pointed to the 80 port , both, Firefox and Chrome caches the content but chrome does not cache when try 443.
Those are the headers i get for a testing image:
Serving by HTTP
Accept-Ranges:bytes
Age:28
Cache-Control:max-age=31536000
Content-Length:190667
Content-Type:image/jpeg
Date:Fri, 18 Dec 2015 12:06:49 GMT
ETag:"5673f678-2e8cb"
Expires:Sat, 17 Dec 2016 12:06:49 GMT
Last-Modified:Fri, 18 Dec 2015 12:05:12 GMT
Served by HTTPS
Accept-Ranges:bytes
Age:74
Cache-Control:max-age=31536000
Connection:keep-alive
Content-Length:190667
Content-Type:image/jpeg
Date:Fri, 18 Dec 2015 12:19:34 GMT
ETag:"5673f678-2e8cb"
Expires:Sat, 17 Dec 2016 12:06:49 GMT
Last-Modified:Fri, 18 Dec 2015 12:05:12 GMT
Anyone knows if this may be a config problem with my servers, or maybe its a chrome normal way of deal with SSL conections?
Thanks
Finally i found the problem.
i remove from the response headers the "Vary: cookies" header and now chrome is locally caching the content served via HTTPS
I have an ASP.NET MVC project under development in VS 2013 and running on localhost. A cookie is sent with the
Set-Cookie: Tx=88440; expires=Sun, 03 Apr 2016 12:49:28 GMT; domain=localhost; path=/
Chrome receives this ok. But when I refreshes the page in Chrome, the cookie Tx is not sent back to the server. Is there anything wrong with the cookie header? Does a path of / mean it will apply to all paths beneath /?
Chrome ignores localhost for cookies. Design decision apparently.
I have made a module in nginx to secure cookie.I encrypted the cookie with AES and modified the original cookie with the encrypted value.
If i modify the original cookie with some other value, then its working fine, say i changed cookie value from abc to xyz it works but when i change abc to encrypted abc chrome is not able to save it.
I can see it in the response headers in chrome, but the cookie is not stored by chrome and not sent by chrome for further requests.
Connection:keep-alive
Content-Length:612
Content-Type:text/html
Date:Sun, 15 Feb 2015 14:00:59 GMT
ETag:"54c1c5ae-264"
Last-Modified:Fri, 23 Jan 2015 03:53:18 GMT
Set-Cookie:my_login=2%B9%B2C%BB%E3%B5 }%EA%E8o%DC%B4%BF%F1%BB%BD|%EA%BF%F2K%A4?m7S%88%A7
Also live http headers extension in chrome shows the value of set-cookie as undefined.
HTTP/1.1 200 OK
Accept-Ranges: bytes
Connection: keep-alive
Content-Length: 612
Content-Type: text/html
Date: Sun, 15 Feb 2015 14:00:59 GMT
ETag: "54c1c5ae-264"
Last-Modified: Fri, 23 Jan 2015 03:53:18 GMT
Set-Cookie: undefined
Any insight will be help.Thanks
1st, you might need to remove whitespaces
2nd, apparently you're sending cookie in a binary format, which can't be set.
here is a quick solution, encrypt this cookie (further) to base64 before sending it to the browser. That should solve your problem.