ISSUE VARY: Proposed wording

Description of Problem

	http://www.w3.org/Protocols/HTTP/Issues/#VARY

- One of the problems in the discussion of content negotiation is that the
term "dimension" in a somewhat obscure manner in Section 12 in parenthesis.
I suggest that we take it up to the terminology section (1.1) using this
description:

    Dimension

    A feature or characteristic involved in a representation
    selection algorithm used by content negotiation.

- In section 12.1 and 12.6 I have removed the detailed description of vary
header and instead put in a reference. The actual description is now
isolated to section 14.43.

Proposed changes to Section 12.1:

<<<<<
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.
=====
HTTP/1.1 origin servers MUST include a Vary header field (see section
14.43) in any cachable response based on server-driven negotiation and
SHOULD include a Vary header field with a non-cachable response based on
server-driven negotiation.

HTTP/1.1 public caches MUST recognize the Vary header field and obey the
requirements described in section 13.6 that describes the interactions
between caching and content negotiation.
>>>>>

Proposed changes to Section 12.3:

<<<<<
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. 
=====
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 (see
section 14.43) in the response if it is cachable to ensure correct
interoperation with all HTTP/1.1 clients.
<<<<<

Proposed changes to Section 13.6:

2nd Paragraph:

<<<<<
A server MUST use the Vary header field (section 14.43) to inform a cache
of what header field dimensions are used to select among multiple
representations of a cachable response. A cache may use the selected
representation (the entity included with that particular response) for
replying to subsequent requests on that resource only when the subsequent
requests have the same or equivalent values for all header fields specified
in the Vary response-header. Requests with a different value for one or
more of those header fields would be forwarded toward the origin server.
=====
A server MUST use the Vary header field (section 14.43) to inform a cache
of what request-header fields were used to select among multiple
representations of a cachable response. A cache may use the selected
representation (the entity included with that particular response) for
replying to subsequent requests on that resource only when the subsequent
requests have the same or equivalent values for all header fields specified
in the Vary response-header. Requests with a different value for one or
more of those header fields SHOULD be forwarded toward the origin server.
>>>>>

4th Paragraph:

<<<<<
The Vary header field may also inform the cache that the representation was
selected using criteria not limited to the request-headers; 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.
=====
The Vary header field MUST also inform the cache that the representation
was selected using criteria not limited to the request-headers; 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.
>>>>>

Section 14.43

1st paragraph:

<<<<<
The Vary response-header field is used by a server to signal that the
response entity was selected from the available representations of the
response using server-driven negotiation (section 12). Field- names listed
in Vary headers are those of request-headers. The Vary field value
indicates either that the given set of header fields encompass the
dimensions over which the representation might vary, or that the dimensions
of variance are unspecified ("*") and thus may vary over any aspect of
future requests.
=====
The Vary response-header field is used by a server to inform caches (see
section 13.6) that the response entity was selected from the available
representations of the response using server-driven negotiation (section
12). Field-names listed in Vary headers are those of request-headers. The
Vary field value indicates either the set of request-header fields
encompassed by the dimensions over which the representation vary at the
time of the response, or leaves the set unspecified ("*"). 
>>>>>

2nd Paragraph:

<<<<<
An HTTP/1.1 server MUST include an appropriate 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 SHOULD include an appropriate 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 might vary.
=====
An HTTP/1.1 server MUST 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
SHOULD 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
vary at the time of the response.
>>>>>

Then I propose to move the 2nd last paragraph in section 14.43 up so that
it comes as number 4 instead. I think it reads a lot better like that. I
have included the rest of the section below - there are no changes except
from the paragraph swap.

*****

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.

When the cache receives a subsequent request whose Request-URI specifies
one or more cache entries including a Vary header, the cache MUST NOT use
such a cache entry to construct a response to the new request unless all of
the headers named in the cached Vary header are present in the new request,
and all of the stored selecting request-headers from the previous request
match the corresponding 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.

A Vary field value of "*" signals that unspecified parameters, possibly
other than the contents of request-header fields (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. See section 13.6 for use of the Vary header by caches.

*****

Comments?

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

Received on Thursday, 3 July 1997 12:25:23 UTC