2

I have a web service which puts an ETag on to each response so future calls can make use of the HTTP 304 (Not Modified) status. The ETag I generate really just a Base64 encoding of the query type along with the timestamp.

The problem I have is if the browser requests the same resource with a difference Accept-Language. The browser currently sends the same If-None-Match header, so the response is a 304, even thought the actual resource would have come back in a different language. So I thought the way to do this was to add a Vary Header, to specify to the client that the response varys with Accept & Accept-Language, as shown below.

Vary:Accept, Accept-Language

However my browser (Chrome) uses the same ETag regardless of the accept-language. What is the correct convention to use here?

Thanks

Agent96
  • 445
  • 1
  • 5
  • 20

1 Answers1

1

E-Tag identifies the response contents. So better use a response body hash for E-Tag construction. At least you can use hash of a query and a language concatenated.

Dmitry T.
  • 673
  • 7
  • 7
  • This seems a bit weak to me, I can encode in the ETag the actual content, but when the client tries to use the same ETag for the same resource in a different language (fr), I will have to simply allocate a new ETag for fr. When the client now queries for the same content again back to the original language, their fr ETag will be ignored and will be passed a new ETag, so they do not make use of 304. This caching solution seems weak given that there is in a specific header to solve this use case (VARY) which informs the client which http headers will affect the output content. – Agent96 Dec 07 '16 at 10:50