4 ms·

if only browsers respected this. none of browsers use ETag and If-None-Match mechanism. instead they do their own wizzardy caching...

demurgos 3y ago
I was refactoring a project serving user uploaded files yesterday, and had the occasion to test caching. Both Firefox and Chrome used ETag and If-None-Match properly to check and cache queries. Which problems did you encounter? There was still one thing that surprised me a bit (but also makes sense). Images are fetched only once per page load in my testing. If an image with 60sec of cache is loaded, then removed by JS and added back after 2 minutes, then the browser will reuse the image from the initial load.
- nikolayasdf123 3y ago
  the issue I got was: 1) I (AWS CloudFront) supply ETag and If-None-Match header; I can see that header in responses. 2) browsers sometimes do respect that (once) I see 304 in responses, but 99% of the time they don't include ETag/If-None-Match in requests and thus I never get 304 responses (albeit AWS CloudFront, resource, data — nothing changed) and instead they perform some other caching and reload whole resource again with TTL that does not seem to come from my headers, totally disregarding ETags/If-None-Match logic. for videos it is even worse. unless you set `preload=none` in html, Safari, Firefox, Chrome will have all different policies trying to preload all videos on screen ignoring lazyload html tags. worse of all, caching does not work well, and videos will be attempted to be loaded almost every time and ETags/If-None-Match totally ignored.
  - withinboredom 3y ago
    It sounds like you have caching disabled in your browser, either in dev-tools itself or through an extension. This is NOT normal behavior.
    - nikolayasdf123 3y ago
      the same happens for all browsers, Chrome, Safari, Firefox with default settings. but do agree this is not normal behavior :/ actually caching is happening, but it does not follow ETags or Caching policy headers that backends return, instead some in-browser internal caching policy being run
      - withinboredom 3y ago
        I’ve never seen the behavior you are describing. I would check that you’re sending the headers correctly: https://neilmadden.blog/2020/05/18/a-flowchart-for-cache-control-headers/ https://neilmadden.blog/2020/05/18/a-flowchart-for-cache-con... I’ve used that flowchart too many times.
        nikolayasdf123 3y ago
        yep, I tried countless variations of this while testing. did not work! my conclusion in the end, this was intentional by browsers. they give priority to the their internal caching policies for performance or user-experience :/
        withinboredom 3y ago
        I don’t think this is true, as I rely on this behavior in an app. You must be doing something weird with your cache-control headers.
rednafi 3y ago
Hmm... Chrome seems to handle this quite well, at least in my experience. I'm curious about what sort of issue you encountered.
- nikolayasdf123 3y ago
  same as above
withinboredom 3y ago
It works correctly. What do you mean?
- nikolayasdf123 3y ago
  look above

demurgos 3y ago

I was refactoring a project serving user uploaded files yesterday, and had the occasion to test caching. Both Firefox and Chrome used ETag and If-None-Match properly to check and cache queries. Which problems did you encounter? There was still one thing that surprised me a bit (but also makes sense). Images are fetched only once per page load in my testing. If an image with 60sec of cache is loaded, then removed by JS and added back after 2 minutes, then the browser will reuse the image from the initial load.

nikolayasdf123 3y ago
the issue I got was: 1) I (AWS CloudFront) supply ETag and If-None-Match header; I can see that header in responses. 2) browsers sometimes do respect that (once) I see 304 in responses, but 99% of the time they don't include ETag/If-None-Match in requests and thus I never get 304 responses (albeit AWS CloudFront, resource, data — nothing changed) and instead they perform some other caching and reload whole resource again with TTL that does not seem to come from my headers, totally disregarding ETags/If-None-Match logic. for videos it is even worse. unless you set `preload=none` in html, Safari, Firefox, Chrome will have all different policies trying to preload all videos on screen ignoring lazyload html tags. worse of all, caching does not work well, and videos will be attempted to be loaded almost every time and ETags/If-None-Match totally ignored.
- withinboredom 3y ago
  It sounds like you have caching disabled in your browser, either in dev-tools itself or through an extension. This is NOT normal behavior.
  - nikolayasdf123 3y ago
    the same happens for all browsers, Chrome, Safari, Firefox with default settings. but do agree this is not normal behavior :/ actually caching is happening, but it does not follow ETags or Caching policy headers that backends return, instead some in-browser internal caching policy being run
    - withinboredom 3y ago
      I’ve never seen the behavior you are describing. I would check that you’re sending the headers correctly: https://neilmadden.blog/2020/05/18/a-flowchart-for-cache-control-headers/ https://neilmadden.blog/2020/05/18/a-flowchart-for-cache-con... I’ve used that flowchart too many times.
      - nikolayasdf123 3y ago
        yep, I tried countless variations of this while testing. did not work! my conclusion in the end, this was intentional by browsers. they give priority to the their internal caching policies for performance or user-experience :/
        withinboredom 3y ago
        I don’t think this is true, as I rely on this behavior in an app. You must be doing something weird with your cache-control headers.

rednafi 3y ago

Hmm... Chrome seems to handle this quite well, at least in my experience. I'm curious about what sort of issue you encountered.

nikolayasdf123 3y ago
same as above

withinboredom 3y ago

It works correctly. What do you mean?

nikolayasdf123 3y ago
look above