W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1997

Re: ISSUE VARY: Proposed wording

From: Henrik Frystyk Nielsen <frystyk@w3.org>
Date: Wed, 30 Jul 1997 14:42:34 -0400
Message-Id: <3.0.3.32.19970730144234.007ced20@pop.w3.org>
To: fielding@kiwi.ics.uci.edu, jg@w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

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 selecting request-headers present in the new request match the
corresponding stored request-headers in the original 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.

A Vary header field-value of "*" always fail to match and subsequent
requests on that resource can only be properly interpreted by the origin
server.

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 a 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 304 (Not Modified), including an entity tag or
Content-Location that indicates which entity should be used.

If an entity tag was assigned to a cached 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 resource.
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 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. 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, MIT/LCS NE43-346
545 Technology Square, Cambridge MA 02139, USA
Received on Wednesday, 30 July 1997 11:55:42 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:50 EDT