Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTTP Caching, a Refresher

danburzo.ro

Post reply on HN
Print view View original

21–30 of 34 posts

Re: HTTP Caching, a Refresher

#21

Post by wyuenho »

danburzo wrote: post #14

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 the TLS cert terminates. In most situation a CDN or a reverse proxy is involved, and the TLC cert you use to encrypt traffic from the origin to the proxy is different from the one the proxy uses to encrypt traffic from it to the browser. Whenever a MITM intermediary is involved, you should read the intermediary's documentation. These usually include Cloudflare, AWS Cloudfront, Akamai etc. With with exceptions, like the Vary header as pointed out elsewhere, these vendors largely follow HTTP caching semantics for proxy caches.

Re: HTTP Caching, a Refresher

#22

Post by loloquwowndueo »

aleksandrm wrote: post #9

This is nothing new and doesn't add anything new to the topic, so am I the only that thinks this is just an attempt at boosting their SEO through HN?

Dunno man, sometimes I write blog posts for my own benefit, to document my knowledge and understanding of something. I could put it in a private note, but I can also put it in my blog and who knows, maybe someone else can benefit from it - even if it’s nothing you couldn’t google research yourself or god forbid, ask an LLM to summarize for you.

No need to be mean and assume the worst possible purpose :)

Re: HTTP Caching, a Refresher

#23

Post by wbadart »

Great write up!

Wanted to highlight MDN's HTTP caching guide[0] that OP links in the conclusion. It's written at a higher level than the underlying reference material and has been a great resource I've turned to several times in the last few years.

[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Cac...

Re: HTTP Caching, a Refresher

#24

Post by afiori »

pat2man wrote: post #13
tekno45 wrote: post #6

Earlier quoted context omitted.

how is https making caching irrelevant?

At one point with http only your isp could do its own cache, large corporate it networks could have a cache, etc. which was very efficient for caching. But horrible for privacy. Now we have CDN edge caching etc but nothing like the multi layer caching that was available with http.

That sounds like it is one expiration bug away from debugging hell

Re: HTTP Caching, a Refresher

#25

Post by KronisLV »

I found that Cache-Control with no-cache worked pretty well EXCEPT Apache2 would fail to return 304 when also compressing some of the resources: https://stackoverflow.com/questions/896974/apache-is-not-sen...

I think setting FileETag None solved it. With that setup, the browser won't use stale JS/CSS/whatever bundles, instead always validating them against the server, but when the browser already has the correct asset downloaded earlier, it will get a 304 and avoid downloading a lot of stuff. Pretty simple and works well for low traffic setups.

It was surprisingly easy to mess up, or having your translation bundles have cached out of date versions in the browser.

(nothing against other web servers, Apache2 was just a good fit for other reasons)

Re: HTTP Caching, a Refresher

#26

Post by bmandale »

Joker_vD wrote: 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

I would say "vary" is the wrong way to solve that problem. The issue is that there can easily be a bunch of stupid inconsequential differences between accept headers, far beyond simply asking for type x versus type y. Slightly different priorities, order, including an extra mime in the list, putting some irrelevant format nobody uses first just in case, etc.

An optimal solution would involve: the response listing which alternate content-types can be returned for that endpoint, the cache considering the accept header, if it sees a type from the alternates list higher in the accept header priority than whatever it has in cache, then it would forward the request to the server. Once it had all the alternatives in cache, it would pass them through according to the accept without hitting the server.

The closest existing header to the above would be the link header, if you give it rel=alternate, and type as the mime type. It's not clear what href you would be, since it usually is to a different document, but we want the same url but a different mime type. So clearly this would be an abuse of the header, but could work.

Re: HTTP Caching, a Refresher

#27

Post by Joker_vD »

bmandale wrote: post #26
Joker_vD wrote: 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

I would say "vary" is the wrong way to solve that problem. The issue is that there can easily be a bunch of stupid inconsequential differences between accept headers, far beyond simply asking for type x versus type y. Slightly different priorities, order, including an extra mime in the list, putting some irrelevant format nobody uses first just in case, etc. An optimal solution would involve: the response listing whi…

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

    GET /media/thumb.jpg HTTP/1.1
    Content-Type: image/jpeg

Re: HTTP Caching, a Refresher

#30

Post by bmandale »

Joker_vD wrote: post #27
bmandale wrote: post #26

Earlier quoted context omitted.

I would say "vary" is the wrong way to solve that problem. The issue is that there can easily be a bunch of stupid inconsequential differences between accept headers, far beyond simply asking for type x versus type y. Slightly different priorities, order, including an extra mime in the list, putting some irrelevant format nobody uses first just in case, etc. An optimal solution would involve: the response listing whi…

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 intended, but it has the downside of initially serving the original format regardless of the content type.

Post reply on HN