Subject: Re: NEW ISSUE: Content-Coding vs ETags

From: Jamie Lokier <[email-masked]>
Date: Thu, 11 Oct 2007 21:03:02 +0100

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

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 12 Oct 2007 16:12:36 +1000

On 01/10/2007, at 4:20 AM, Julian Reschke wrote:

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

I think this is the flip side of <http://www.w3.org/Protocols/HTTP/ 
1.1/rfc2616bis/issues/#i37>. I'm happy to leave it at that, unless  
people feel strongly that it's a separate issue.

--
Mark Nottingham     http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Fri, 12 Oct 2007 10:03:57 +0200

Mark Nottingham wrote:
> I think this is the flip side of 
> <http://www.w3.org/Protocols/HTTP/1.1/rfc2616bis/issues/#i37>. I'm happy 
> to leave it at that, unless people feel strongly that it's a separate 
> issue.

Indeed - I just forgot that we already have that on the list.

Best regards, Julian