W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2007

Re: NEW ISSUE: Content-Coding vs ETags

From: Jamie Lokier <jamie@shareable.org>
Date: Thu, 11 Oct 2007 21:03:02 +0100
To: Henrik Nordstrom <henrik@henriknordstrom.net>
Cc: Julian Reschke <julian.reschke@gmx.de>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <20071011200302.GA17452@mail.shareable.org>

Henrik Nordstrom wrote:
> On sön, 2007-09-30 at 20:20 +0200, Julian Reschke wrote:
> 
> > ...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.
> 
> Any specific areas you have in mind, other than a lot of people getting
> this wrong by making assumptions and not reading the specs?
> 
> > 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.
> 
> 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.

I agree with Henrik on this.

Omitting headers that weren't in the request will break variant-caching.

This means IIS7 is broken, and every high quality intermediate cache
will have to implement a workaround when detecting IIS7 as the server.

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

I agree with Henrik on this too (the outocome of the discussion, not
his original idea :-)

-- Jamie

ps. (One last thing which would help some dynamically generated resources
is a way to specific 'Vary', reliably, after transmitting some or all
of the body.  There's no way to do this at the moment (trailers can't
be relied upon), so a dynamically generated resource currently needs
to run in two phases on a server: First phase, to compute what request
headers various parts of the computed body will depend on; second
phase to actually generate the body.  But perhaps that's in the realm
of "asking for too much from HTTP's caching model" :-).
Received on Thursday, 11 October 2007 20:09:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:22 GMT