Subject: NEW ISSUE: Content-Coding vs ETags

From: Julian Reschke <[email-masked]>
Date: Sun, 30 Sep 2007 20:20:46 +0200

Hi,

...as summarized today by Sam Ruby 
(<http://intertwingly.net/blog/2007/09/30/Etag-vs-Encoding>).

My feeling is that over here there is indeed consensus that using 
Content Coding indeed is a case of server driven content-negotiation; 
but it's also pretty clear that there are places in the spec that could 
be read differently. Let's clarify those.

Related to that, it's (IMHO) also not clear at all whether you need to 
use "Vary" on the response if the request didn't contain the header 
you're varying on. My reading was that yes, you need to do so, but 
that's not what IIS7 does (which at least gets the ETag right), and as 
far as I recall, Henrik N. argued the other way in the past.

Best regards, Julian

---

From: Henrik Nordstrom <[email-masked]>
Date: Sun, 30 Sep 2007 23:15:54 +0200

> be read differently. Let's clarify those.

Any specific areas you have in mind, other than a lot of people getting
this wrong by making assumptions and not reading the specs?

> far as I recall, Henrik N. argued the other way in the past.

No, I have always argued that Vary must lists the headers you looked for
in determining which variant to respond with, not only the headers your
found in the request. A non-existing header is also a value, and has
different outcome on the server decision than an existing header with a
certain value so it must be listed in Vary or caching of vary:ing
responses will fail very badly.

Others have asked if this is needed, but the specs is pretty clear on
this I think.

I have even argued that Vary should list all headers you might look for
when determining the variant (on a per resource basis) but after
discussion here agrees that it's just the headers you looked for when
determining the outcome of the given request, which may be different for
another request depending on the variance capabilities of the resource.
(i.e. English page existing in both normal and gzip:ed content-encoding,
while Swedish page only in normal encoding).

Regards
Henrik