Live data from Hacker News

HTTP Caching, a Refresher

danburzo.ro

31–34 of 34 posts

Re: HTTP Caching, a Refresher

#31

Earlier quoted context omitted.

That's tangentially related to the Vary header. Not only Accept can go into its value, you know. And an optimal solution IMHO would be for the origin server to simply return 302 to a specific resource, selected upon the value of the Accept header: GET /thumb.php?id=kekw HTTP/1.1 Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8 HTTP/1.1 302 Found Location: /media/thumb.jpg?id=kekw Vary: Accept…

Sure, except I doubt most people want to uglify all their urls with extensions for occasional alternates. Plus, if the url with the extension gets past around instead of the original (as would inevitably be done) you're back to square one. I had thought about recommending that people just use an alternate link as intended, to point to an alternate format. I think that would work best using existing web standards as i…

> if the url with the extension gets past around instead of the original (as would inevitably be done) you're back to square one.

Why? It has no "Vary" header, and it's the one that's supposed to get cached anyhow.

Re: HTTP Caching, a Refresher

#32

Earlier quoted context omitted.

Sure, except I doubt most people want to uglify all their urls with extensions for occasional alternates. Plus, if the url with the extension gets past around instead of the original (as would inevitably be done) you're back to square one. I had thought about recommending that people just use an alternate link as intended, to point to an alternate format. I think that would work best using existing web standards as i…

> if the url with the extension gets past around instead of the original (as would inevitably be done) you're back to square one. Why? It has no "Vary" header, and it's the one that's supposed to get cached anyhow.

If people see it in the url bar and copy paste it from there. In the case of images if they "copy image url".

Re: HTTP Caching, a Refresher

#33
post #7

As is traditional with most explanations of HTTP caching, it doesn't mention Vary header. Although apparently some CDNs (e.g. Cloudflare) straight up ignore it for some reason [0]. [0] https://news.ycombinator.com/item?id=38346382

Good call! Honestly I just wanted to wrap it up before the holidays, but you’re right that a small section on Vary would have been useful. Things like non-conforming caching services made me punt actual suggestions to a later article, as I wasn’t sure how my sense of the RFC interacted with the real world. HTTP Caching Tests seems like a great resource for this, but only includes Fastly out of the big providers, and…

Updated the article with some information on the `Vary` and `No-Vary-Search` headers. I’ve left out the details of how revalidation works with `Vary` since I haven’t been able to reconcile yet what the spec seems to encourage vs what the tests on cache-tests.fyi suggest is conformant behavior.

Re: HTTP Caching, a Refresher

#34
post #21

As many have pointed out here, the nature of caching has changed in the current climate of ubiquitous HTTPS, and I want to add a paragraph or two about it. Is there a good summary somewhere that I could reference? What are the the usual, most prevalent uses of HTTP intermediaries involving caches, besides CDNs and origin-controlled caches (eg Varnish)?

HN is full of noobs loudly proclaiming what they don't know is true these days. Ubiquitous HTTPS does not change the nature of private browser caches, and only nullify the proxy related cache headers if the origin encrypts traffic all the way to the client, which is quite rare in real life, unless we are merely talking about a dude serving this blog from his basement computer. In general, your answer depends on where…

Thanks! I’ve updated the introduction with some ‘now vs then’ pointers.
Post reply on HN