4 ms·
I don't think this is the case, not in Chrome anyway. See http://www.youtube.com/watch?v=q7QL0NAwES8 http://www.youtube.com/watch?v=q7QL0NAwES8 - All files are
by jaffathecake 14y ago
I don't think this is the case, not in Chrome anyway.
See http://www.youtube.com/watch?v=q7QL0NAwES8 http://www.youtube.com/watch?v=q7QL0NAwES8 - All files are "must-revalidate" except the JS file which is far-future cached. When the manifest is changed an update is triggered, all files are updated except the JS file, which is assumed to be fresh because of the far future expiry.
You see similar behaviour when no caching headers are served, heuristics take over & files may be updated from the normal browser cache rather than going to the server.
- saurik 14y agoI will then be much more specific and say "MobileSafari". My mobile application is part of an iOS application, so I only use and care about MobileSafari as a target. I definitely am quite careful with my Cache-Control headers, and am documenting this not just with logs but with WebKit code. (edit/clarification: While I get this code from the WebKit repository, I forgot that the specific area of WebKit I'm looking at is WebCore, so I should really be calling it WebCore and not WebKit, considering they are separate libraries and quite separate projects on some platforms.) Someone else I know (who may or may not decide to actually chime in) saw this interaction and decided to do some tests with various browsers, stating that 1) Safari worked as I said, 2) Firefox refetched the request but did not set the Cache-Control header, and 3) Chrome worked as you say.
- jaffathecake 14y agoConfirmed! Interesting. Safari on OSX and iOS makes the request regardless. Firefox didn't request the far-future file, but also didn't request one of the must-revalidate files. Not sure what it's doing. Good spot.