Re: ISSUE VARY: Proposed wording

The first part is fine.

>13.6 Caching Negotiated Responses
>
>Use of server-driven content negotiation (section 12), as indicated by the
>presence of a Vary header field in a response, alters the conditions and
>procedure by which a cache can use the response for subsequent requests.
>See section 14.43 for use of the Vary header field by servers.
>
>A server SHOULD use the Vary header field to inform a cache of what
>request-header fields were used to select among multiple representations of
>a cachable response subject to server-driven negotiation. The set of header
>fields named by the Vary field value is known as the "selecting"
>request-headers.
>
>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 selecting request-headers from two requests are defined to match if and
>only if the selecting request-headers in the first request can be
>transformed to the selecting request-headers in the second request by
>adding or removing linear whitespace (LWS) at places where this is allowed
>by the corresponding BNF, and/or combining multiple message-header fields
>with the same field name following the rules about message headers in
>section 4.2.
>
>If the selecting request-headers do not match, then the cache MUST forward
>the request to the origin server; it MAY forward the request as a
>conditional request.

This is wrong as well -- we cannot require the cache to make a request.
The only thing we can require is that it not use the existing response
to satisfy the new request unless it is confirmed by a 304 response
from the next server in the request chain.

>If an entity tag was assigned to the representation, the forwarded request
>SHOULD be conditional and include the entity tags in an If-None-Match
>header field from all its cache entries for the Request-URI. This conveys
>to the server the set of entities currently held by the cache, so that if
>any one of these entities matches the requested entity, the server can use
>the ETag header field in its 304 (Not Modified) response to tell the cache
>which entry is appropriate. If the entity-tag of the new response matches
>that of an existing entry, the new response SHOULD be used to update the
>header fields of the existing entry, and the result MUST be returned to the
>client.
>
>If the representation was selected using criteria not limited to the
>request-headers, then the server SHOULD include a "Vary: *" header field in
>the response if it is cachable. In this case, a cache MUST NOT use the
>response in a reply to a subsequent request unless the cache relays the new
>request to the origin server in a conditional request and the server
>responds with 304 (Not Modified), including an entity tag or
>Content-Location that indicates which entity should be used.

This is getting convoluted and also a bit repetitive.  We should only
talk about what it means to "match" first, and then just explain what
must be done if it doesn't match.  In other words

   If the response includes a Vary header field with a field-value of "*",
   indicating that the representation was selected using criteria not
   limited to the original request header fields, then subsequent
   requests always fail to match the selecting request header fields.

   If the selecting request header fields for the cached entry do not
   match the selecting request header fields of the new request, then
   the cache MUST NOT use the cached entry to satisfy the request unless
   it first relays the new request to the origin server in a conditional
   request and the server responds with a 304 (Not Modified) response
   indicating that the cached entry can be reused.

That way, we don't have to repeat it for every single condition.
Still a bit of a tongue-twister -- why don't we just call them
"selecting fields"?

>If any of the existing cache entries contains only partial content for the
>associated entity, its entity-tag SHOULD NOT be included in the
>If-None-Match header field unless the request is for a range that would be
>fully satisfied by that entry.
> 
>If a cache receives a successful response whose Content-Location field
>matches that of an existing cache entry for the same Request-URI, whose
>entity-tag differs from that of the existing entry, and whose Date is more
>recent than that of the existing entry, the existing entry SHOULD NOT be
>returned in response to future requests, and should be deleted from the cache.

>14.43 Vary
>
>The Vary field value indicates the set of request-header fields that fully
>determines, while the response is fresh, whether a cache may use the
>response to reply to a subsequent request without revalidation. For
>uncachable or stale responses, the Vary field value advises the user agent
>about the criteria that were used to select the representation. A Vary
>field value of "*" implies that a cache cannot determine from the request
>headers of a subsequent request whether this response is the appropriate
>representation. See section 13.6 for use of the Vary header field by caches.
>
>       Vary  = "Vary" ":" ( "*" | 1#field-name )
>
>An HTTP/1.1 server SHOULD include a Vary header field with any cachable
>response that is subject to server-driven negotiation. Doing so allows a
>cache to properly interpret future requests on that resource and informs
>the user agent about the presence of negotiation on that resource. A server
>MAY include a Vary header field with a non-cachable response that is
>subject to server-driven negotiation, since this might provide the user
>agent with useful information about the dimensions over which the response
>varies at the time of the response.
>
>A Vary field value consisting of a list of field-names signals that the
>representation selected for the response is based on a selection algorithm
>which considers ONLY the listed request-header field values in selecting
>the most appropriate representation. A cache MAY assume that the same
>selection will be made for future requests with the same values for the
>listed field names, for the duration of time in which the response is fresh.
>
>The field-names given are not limited to the set of standard request-header
>fields defined by this specification. Field names are case-insensitive.
>
>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.

.....Roy

Received on Friday, 18 July 1997 07:34:44 UTC