HTTP Caching, a Refresher

180 points by danburzo 145 days ago | 33 comments

Joker_vD 145 days ago |

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

JimDabell 145 days ago | |

There was a recent discussion on X about this that had a couple of Cloudflare people chip in, including their CTO:

https://xcancel.com/simonw/status/1988984600346128664

lucideer 145 days ago | | |

The highlight from that thread https://xcancel.com/dok2001/status/1989005141450846470#m

bmandale 145 days ago | |

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.

Joker_vD 144 days ago | | |

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

danburzo 145 days ago | |

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 it seems to be doing okay with Vary. https://cache-tests.fyi/

danburzo 141 days ago | | |

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.

paulddraper 145 days ago | |

Vary is Very important.

> the cache MUST NOT use that stored response without revalidation unless all the presented request header fields nominated by that Vary field value match those fields in the original request

You’ll find that some have creative readings of MUST NOT.

wbadart 145 days ago |

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...

KronisLV 145 days ago |

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)

danburzo 145 days ago |

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)?

wyuenho 145 days ago | |

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.

danburzo 141 days ago | | |

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

nesarkvechnep 144 days ago |

For 10+ years in the industry I can safely say that almost nobody knows or cares about HTTP caching. It’s sad.

aleksandrm 145 days ago |

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?

masklinn 145 days ago | |

It clearly notes that it's "a refresher", does not claim that it's novel research, and extensively links to the reference documents. It is, essentially, a review article (https://en.wikipedia.org/wiki/Review_article). And there's absolutely nothing wrong with that.

Hell, the author could probably have called it a primer and I think it'd have been fair.

loloquwowndueo 145 days ago | |

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 :)

danburzo 145 days ago | |

I’m sorry you didn’t get anything out of it. I wasn’t operating at the edge of caching knowledge, just a person refreshing and clarifying for themselves how caching works. Some things were new to me, and after spending so much time with the RFC, I just thought others may benefit or, more selfishly, would point out errors or ways to make it better.

I mean, do those <meta> tags really suggest someone who’s into SEO? Call me stale but what I really want is validation :-)

baggy_trough 145 days ago |

A lot of this seems irrelevant these days with https everywhere.

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