Re: ISSUE VARY: Proposed wording

This is what I believe to be the consensus between Jeff Mogul, Dave Morris,
Koen, and myself regarding rewording the description of the Vary header
field in section 12.1, 12.3, 13.6 and 14.43. This text is to completely
replace the existing wording in section 13.6 and 14.43 and to edit section
12.1 and 12.3

**********

12.1 Server-driven Negotiation

Change the last two paragraphs from

   HTTP/1.1 origin servers MUST include an appropriate Vary header
   field (section 14.43) in any cachable response based on server-
   driven negotiation. The Vary header field describes the 
   dimensions over which the response might vary (i.e. the 
   dimensions over which the origin server picks its "best guess" 
   response from multiple representations).

   HTTP/1.1 public caches MUST recognize the Vary header field
   when it is included in a response and obey the requirements 
   described in section 13.6 that describes the interactions
   between caching and content negotiation.

to

   The Vary header field can be used to express the parameters used
   to select a representation subject to server-driven negotiation.
   See section 13.6 for use of the Vary header field by caches and
   section 14.43 for use of the Vary header field by servers.

12.3 Transparent Negotiation

Change the last paragraph from

   This specification does not define any mechanism for
   transparent negotiation, though it also does not prevent any 
   such mechanism from being developed as an extension and used 
   within HTTP/1.1. An HTTP/1.1 cache performing transparent 
   negotiation MUST include a Vary header field in the response 
   (defining the dimensions of its variance) if it is cachable to 
   ensure correct interoperation with all HTTP/1.1 clients. The 
   agent-driven negotiation information supplied by the origin 
   server SHOULD be included with the transparently negotiated 
   response.

to

   This specification does not define any mechanism for
   transparent negotiation, though it also does not prevent any 
   such mechanism from being developed as an extension and used 
   within HTTP/1.1.

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. 

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.

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.

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.

**********

Henrik
--
Henrik Frystyk Nielsen, <frystyk@w3.org>
World Wide Web Consortium
http://www.w3.org/People/Frystyk

Received on Thursday, 17 July 1997 14:08:55 UTC