Re: ETags vs Variants, was: Revising RFC2616 - what's happening

On Oct 20, 2006, at 5:28 AM, Julian Reschke wrote:
> Henrik Nordstrom schrieb:
>> tor 2006-10-19 klockan 22:56 +0100 skrev Jamie Lokier:
>>> While on the subject of Etag and variants, it's never been clear  
>>> what
>>> a Vary header that names a header not in the original request means.
>> For me that never was a question. I immediately read Vary as the
>> complete list of headers the server looked for while selecting which
>> variant to send. But this may be just my reading of the RFC..
>
> It doesn't help that "Vary" is described in two places, Section  
> 13.6 and  14.44.
>
> In 13.6 it says:
>
> "When the cache receives a subsequent request whose Request-URI  
> specifies one or more cache entries including a Vary header field,  
> the cache MUST NOT use such a cache entry to construct a response  
> to the new request unless all of the selecting request-headers  
> present in the new request match the corresponding stored request- 
> headers in the original request." (<http://greenbytes.de/tech/ 
> webdav/rfc2616.html#rfc.section.13.6>)
>
> At least this part IMHO needs to be fixed to say how to treat the  
> case where a header doesn't appear in the request.

Why?  That seems completely unambiguous to me, and I have a hard time
believing that any implementer would fail to understand that a missing
header field is different from a present header field.  Would it be
more clear if we replaced "all of the" with "the set of"?  I.e.,

"When the cache receives a subsequent request whose Request-URI  
specifies one or more cache entries including a Vary header field,  
the cache MUST NOT use such a cache entry to construct a response to  
the new request unless the set of selecting request-headers present  
in the new request match the corresponding set of
stored request-headers in the original request."

> One of the reasons may be broken handling of Vary headers in user  
> agents, mainly IE (<http://support.microsoft.com/default.aspx? 
> scid=kb;en-us;824847>), but also Firefox (<https:// 
> bugzilla.mozilla.org/show_bug.cgi?id=269303#c30>).

Yes, though for different reasons.  MSIE doesn't handle Vary because  
some
person interpreted the HTTP caching DLL to be a "shared cache" (even
though it never is in practice) because multiple user agents might use
the same DLL for requests, and it was "too complicated" to get it right.
Mainly because the library doesn't know its own header fields. *shrug*

That is why waka includes the "what this response is good for" algorithm
in each response message.

....Roy

Received on Friday, 20 October 2006 18:17:13 UTC