Content Negotiation header on not quite correct

(Evert Meulie) #1

REDbot: <> states under Content Negotiation:

This response is negotiated, but doesn’t have an appropriate Vary header.

All content negotiated responses need to have a Vary header that reflects the header(s) used to select the response.
This response was negotiated for gzip content encoding, so the Vary header needs to contain Accept-Encoding, the request header used.

(Jeff Atwood) #2

Not sure if this matters; are there any clients that really can’t accept gzip these days?

Adding it doubles the number of cache objects for imho no good reason, meaning, every cache will need to store both compressed and uncompressed representations of every url.

(Dean Taylor) #3

@codinghorror surely it will only double the cache objects if non-gzip requests are made. If your statement is true there should be no change in cache objects right?

(Kane York) #4

From the linked article:

You might wonder if all browsers these days send the same Accept-Encoding header.

Unfortunately, the answer is no.

I sampled 100,000 requests on one of our caches, and got 44 different Accept-Encoding headers. (For those interested in how I did that, or the numbers, see here)

(Dean Taylor) #5

@riking yeap - that’s not doubling - fun times.

I remember if you are doing any kind of automatic WebP vs other image format serving depending on browser support you need Vary: Accept.

(Jeff Atwood) #6

I think @sam fixed this a few days ago?

(Sam Saffron) #7

Yes I did.

For the record the reason you do this is vary important

(Jeff Atwood) #8