Re: ISSUE VARY: Proposed wording

Roy, Jim,

This mail contains some discussion - the next mail contains the full wording.

>>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 field-names in the cached Vary header field are present in the
>>new request, and all of the stored selecting request-headers from the
>>previous request match the corresponding request-headers in the new
request. 
>
>That's not quite right -- if the field-name is missing from both the
>old request and the new request, then they still match.  We should also
>be referring to the requested resource rather than the Request-URI.

The rule should be that if a selecting request-header is not present in a
new request then this always matches any value that this request-header had
in the original request. This follows the accept* rule that no accept
header means "anything goes" and allows for clients that don't know about a
specific selecting request-header still to obtain a cached version.
Something like this:

   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. 

>>A Vary field value of "*" signals that unspecified parameters not limited
>>to the request-headers (e.g., the network address of the client), play a
>>role in the selection of the response representation. Subsequent requests
>>on that resource can only be properly interpreted by the origin server, and
>>thus a cache MUST forward a (possibly conditional) request even when it has
>>a fresh response cached for the resource. The "*" value MUST NOT be
>>generated by a proxy server; it may only be generated by an origin server.
>
>This section is great up until this last paragraph.  Since it just repeats
>what is already said in the first paragraph, we should delete it.  As
>mentioned above, we cannot place a MUST requirement on the cache making
>a new request (i.e., the cache must have the right to deny service).
>Also, the requirement in the last sentence is bogus, unless we mean
>to apply it to all values of Vary (i.e., The Vary field MUST NOT be
>set or modified by any application other than the origin server.).
>The existing wording is always a contradiction for the CERN server.

There is nothing wrong in that a cache "creates" a new representation by
converting it on the fly and store both versions in its cache. For example,
a cache can translate a GIF image into a PNG image and maintain both
versions in the cache. The remaining metainformation is cloned from the
original version but the cache can add or modify a Vary header to indicate
that there now are two representations.

The further away the cache gets from the origin server, the chance of
"going around it" increases but this will not lead to a correctness problem
- only a conditional request to the origin server. However, a value of "*"
doesn't make sense. It would have the same result as a must-revalidate
cache control directive.

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium, MIT/LCS NE43-346
545 Technology Square, Cambridge MA 02139, USA

Received on Wednesday, 30 July 1997 11:51:24 UTC