6

As we all know, sending a response header Vary: Some-Header causes (or should cause) caches to store different variants of the response, one for each value of Some-Header: it encounters in requests. However, this method has drawbacks with headers that show enormous variation, such as User-Agent: or Accept-Language:.

Let's say our server wants to vary based on such a very variable header, but really just serves a handful of variants. I think the followin almost works:

  • The server uses all request headers to determine which variant to serve; let's assume it decides to send variant #42
  • The server sends Etag: variant42-version1 and Vary: If-none-match
  • The next time this user wants to access the page, it presumably adds If-none-match: variant42-version1 and therefore tries to retrieve that from the cache
  • However, there is no such entry in the cache. But a fresh query from the server will cause a response with that Etag again, which will be cached for the future
  • If the same user wants to access the page a third time, he will again add If-none-match: variant42-version1 and this time be served the cached content

The problem with this is the initial case of no Etag at all. Those are the first time visitors for which the complicated evaluation which version to serve needs to be performed - but specifically for these we would still need to vary with the original headers instead of If-none-match ... a vicious circle.

Can this be made work? (Or can the desired effect of reducing cachable variants be achieved differently?)

Improve this question
4
  • It sounds like you are trying to achieve something similar to either A/B testing or serving specific versions of a page based on data such as a user-agent string. Can you please advise the reason if possible, why you are trying to achieve variant served pages, that will make answering making it work or achieving the desired effect differently, easier.
    – Chris Rutherfurd
    Oct 13, 2016 at 4:19
  • @PlanetScaleNetworks it could be just a dynamic serving of mobile/desktop content, which is truly popular
    – Evgeniy
    Jan 21, 2017 at 18:52
  • @Evgeniy Actually, my original desire was mainly for Accept-Language:. If I only have an English and a German version available, and a client says "I'm a natve speaker of French, quite good at Russian, understand quite a bit of German, but no English at all" the server will send the German version; thus I'd rather have this occupy only the same slot as the German version served to a client stating "I understand German and nothing else"
    – Hagen von Eitzen
    Jan 21, 2017 at 23:41
  • If you find this answer helpful to you, please accept this answer as correct.
    – Steve
    Mar 25, 2017 at 22:29

1 Answer 1

Reset to default
2

Based on your question and your clarification comment you would be better served using the URL rather than a header in order to best deal with downstream caching servers. In other words the first time you get the connection check the language header and then redirect them to the appropriate content via URL (something like www.domain.com/en/ or www.domain.com/de). By doing this you will not have to do anything special for caching servers. Additionally some caching servers are not correctly configured to support variants on pages and so can break the header based language changes (the user wants German language but the English version is cached and returned from the caching server).

Even the largest sites on the internet such as Microsoft put the language code into the URL to ensure the best support for downstream caching servers.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.