W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

(CONTENT NEGOTIATION,VARY) Draft text for Vary header and content negotiation `hooks'

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 2 Apr 1996 00:48:19 +0200 (MET DST)
Message-Id: <199604012248.AAA09357@wsooti04.win.tue.nl>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: Koen Holtman <koen@win.tue.nl>

As I said in my earlier message about strategy:

- Section 12 of the old 1.1 draft (which gave an incomplete definition
of a content negotiation mechanism) will not be present in the new 1.1
draft.

- There will be a Vary header in the 1.1 draft, so that HTTP/1.1 can
support opaque negotiation on language in a reasonably efficient
way.

- There will be `hooks' in the 1.1 draft to ensure that all HTTP/1.1
caches will be compatible, though not in an optimally efficient way,
with a transparent content negotiation mechanisms like the mechanism
defined in draft-holtman.  Thus, transparent content negotiation
(which is what Section 12 of the old 1.1 draft covered incompletely)
won't have to wait for HTTP/1.2 if HTTP/1.2 turns out to take too
long, it can be done on top of HTTP/1.1. 

- The `hooks' for transparent content negotiation consist mainly of an
Alternates header definition which defines the Alternates header as
synonymous with a certain Vary header.  Also, some language in the
draft will announce that a negotiation mechanism using Alternates is
planned.

The sections below are proposed as new or changed text for the current
1.1 draft.

If you have comments on this text, now is the time to comment.  I
intend to close this issue at the end of the week.  This means that I
will send a last call for disagreement with perceived consensus,
together with a possibly improved version of the text below, in a few
days.  If I get many negative reactions, the one-week schedule will of
course be reconsidered.

There are no change bars, all text below is new, though it is mostly
based on old ideas.

--snip--


** I. Vary+content negotiation new/changed header descriptions

[##Note: The current section 12 needs to be deleted completely from the
April 1.1 draft.##]

10.v  Vary

   The Vary response-header field is used by origin servers to signal
   that the resource identified by the request-URI and the Host
   request header (present if the request-URI is not an absoluteURI)
   has the capability to send different responses depending on the
   contents of particular header fields in the request message, and
   maybe even depending on other information pertaining to the
   request, for example the network address of the sending client.
   Resources that have this capability are called varying resources.
   Responses from varying resources must contain at least one Vary
   header or Alternates header (Section 10.a) to signal this variance.
   If a resource is varying, this has an important effect on cache
   management, particularly for caching proxies which service a
   diverse set of user agents.

   If no Vary headers and no Alternates headers are present in a
   response, then caches may assume, as long as the response is fresh,
   that the resource in question is not varying.  Note however that
   the fixed response that will be sent by an un-varying resource can
   still change through time, as possibly indicated by a Cache-Control
   response header (section 10.cc).  Also, if an un-varying resource
   is access authenticated, its response can always change depending
   on the presence of an Authorization request header (Section
   10.auth), and depending on the contents of this Authorization
   request header if present.

   Request headers whose contents are used by a varying resource to
   select its response are called selecting request headers.  The Vary
   header field specifies selecting request headers and any other
   selection parameters used by the varying resource.

       Vary                 = "Vary" ":" 1#selection-parameter

       selection-parameter  = field-name
                            | "{" "accept-headers" "}"
                            | "{" "other" "}"
                            | "{" "unknown" "}"
                            | "{" extension-parameter "}"

       extension-parameter  = token

   The presence of a field-name signals that the request-header field
   with this name is selecting.  The field-name will usually be, but
   need not be, a request-header field name defined in this
   specification.  Note that field names are case-insensitive.  The
   presence of the "accept-headers" parameter signals that all request
   headers whose names start with "accept" are selecting.

   The inclusion of the "other" parameter in a Vary field signals that
   parameters other than the contents of request headers, for example
   the network address of the sending party, play a role in the
   selection of the response.  The "unknown" parameter signals that
   the origin server is not willing or able to specify the selection
   parameters used.  If an extension-parameter unknown to the cache is
   present in a Vary header, the cache must treat it as the "unknown"
   parameter.

   If multiple Vary and Alternates header fields are present in a
   response, these must be combined to give all selecting parameters.
   Note that the inclusion of the field names "Host" or
   "Authorization" into a Vary response header is always redundant.

   A cache may always store the relayed 200 (OK) responses from a
   varying resource, and can refresh them according to the rules in
   Section aa.bb [##Which will be written by Jeff Mogul##].  When
   getting a request on a varying resource, a cache can only return a
   cached response to one of its clients in two particular cases.

   First, if a cache gets a request on a varying resource for which it
   has cached one or more responses with Vary or Alternates headers,
   it can relay that request towards the origin server, adding an
   Unless-Cval [##or Unless-VID, exact names to be specified by Jeff
   Mogul##] header listing the cache validators in the Cval headers of
   the cached responses.  If it then gets back a 3xx (Ppp Qqq) [##TBS
   ##] response with the cache validator of a cached 200 (OK) response
   in its Cval header, it can return this cached 200 (OK) response to
   its client, after merging in any of the 3xx response headers as
   specified in Section xx.yy [##Which will be written by Jeff
   Mogul##].

   Second, if a cache gets a request on a varying resource, it can
   return to its client a cached, fresh 200 (OK) response which has
   Vary or Alternates headers, provided that

       - the Vary and Alternates headers of this fresh response
         specify that only request header fields are selecting
         parameters,

       - the specified selecting request header fields of the current
         request match the specified selecting request header fields
         of a previous request on the resource relayed towards the
         origin server,

       - this previous request got a 200 (OK) or 3xx (Ppp Qqq)
         response which had the same cache validator in its CVal header
         as the cached, fresh 200 (OK) response.

   Two sequences of selecting request header fields match if and only
   if the first sequence can be transformed into the second sequence
   by only adding or removing whitespace at places in fields where
   this is allowed according to the syntax rules in this
   specification.

   [##Note that a more complicated matching rule could be defined in a
   future specification.  The rule above reflects the consensus of the
   editorial group on how complex we can get in HTTP/1.1##]

         Note: Implementation of support for the second case above is
         mainly interesting in user agent caches, as a user agent
         cache will generally have an easy way of determining whether
         the sequence of request header fields of the current request
         equals the sequence sent in an earlier request on the same
         resource.  Proxy caches supporting the second case would have
         to record diverse sequences of request header fields
         previously relayed; the implementation effort associated with
         this may not be balanced by a sufficient payoff in traffic
         savings.  A planned specification of a content negotiation
         mechanism will define additional cases in which proxy caches
         can return a cached 200 (OK) response without contacting the
         origin server.  The implementation effort associated with
         support for these additional cases is expected to have a much
         better cost/benefit ratio.

  [##Note that the `planned specification of a content negotiation
  mechanism' above does not necessarily have to be draft-holtman!'  In
  theory, a content negotiation mechanism totally unlike draft-holtman
  could just as well live up to these cost/benefit expectations.##]

10.a  Alternates

   The Alternates response-header field is used by origin servers to
   signal that the resource identified by the request-URI and the Host
   request header (present if the request-URI is not an absoluteURI)
   has the capability to send different responses depending on the
   accept headers in the request message.  This has an important
   effect on cache management, particularly for caching proxies which
   service a diverse set of user agents.  This effect is covered in
   Section 10.v.

       Alternates           = "Alternates" ":" opaque-field

       opaque-field         = field-value

   The Alternates header is included into HTTP/1.1 to make HTTP/1.1
   caches compatible with a planned content negotiation mechanism.
   HTTP/1.1 allows a future content negotiation standard to define the
   format of the Alternates header field-value, as long as the defined
   format satisfies the general rules in Section 4.2.

   To ensure compatibility with future experimental or standardized
   software, caching HTTP/1.1 clients must treat all Alternates
   headers in a response as synonymous to the following Vary header:

         Vary: {accept-headers}

   and follow the caching rules associated with the presence of this
   Vary header, as covered in Section 10.v.  HTTP/1.1 allows origin
   servers to send Alternates headers under experimental conditions.


10.u  URI

   The URI entity-header field is used to inform the recipient of
   other Uniform Resource Identifiers (Section 3.2) by which
   the resource can be identified.

       URI-header  = "URI" ":" 1#( uri-mirror | uri-name )

       uri-mirror  = "{" "mirror" <"> URI <"> "}"
       uri-name    = "{" "name" <"> URI <"> "}"

   Any URI specified in this field can be absolute or relative to the
   Request-URI. The "mirror" form of URI refers to a location which is a
   mirror copy of the Request-URI. The "name" form refers to a
   location-independent name corresponding to the Request-URI.

   [##Note: According to the issues list, Roy is working on text that
   explains better what "mirror" and "name" actually mean.##]


** II. Changed status code descriptions

300 Multiple Choices

   This status code is reserved for future use by a planned content
   negotiation mechanism.  HTTP/1.1 user agents receiving a 300
   response which includes a Location header can treat this response
   as they would treat a 303 (See Other) response.  If no Location
   header is included, the appropriate action is to display the entity
   enclosed in the response to the user.

406 None Acceptable

   This status code is reserved for future use by a planned content
   negotiation mechanism.  HTTP/1.1 user agents receiving a 406
   response which includes a Location header can treat this response
   as they would treat a 303 (See Other) response.  If no Location
   header is included, the appropriate action is to display the entity
   enclosed in the response to the user.


** III.  New text for the (new) caching section

13.x Interoperability of varying resources with HTTP/1.0 proxy caches

  [## Note: the text in 13.x could be part of a larger subsection in
  the 1.1 document##]

  If the correct handling of responses from a varying resource
  (Section 10.v) by HTTP/1.0 proxy caches in the response chain is
  important, HTTP/1.1 origin servers can include the following Expires
  (Section 10.exp) response header in all responses from the varying
  resource:

     Expires: Thu, 01 Jan 1980 00:00:00 GMT

  If this Expires header is included, the server should usually also
  include a Cache-Control header for the benefit of HTTP/1.1 caches,
  for example

     Cache-Control: max-age=604800

  which overrides the freshness lifetime of zero seconds specified by
  the included Expires header.


13.y Cache replacement for varying resources

  If a new 200 (OK) response is received from a non-varying resource
  while an old 200 (OK) response is cached, caches can delete this old
  response from cache memory and insert the new response.  For 200
  (OK) responses from varying resources (Section 10.v), cache
  replacement is more complex.

  HTTP/1.1 allows the authors of varying resources to guide cache
  replacement by the inclusion of elements of so-called replacement
  keys in the responses of these resources.  The replacement key of a
  varying response consists of two elements, both of which may be
  empty strings, separated by a semicolon:

       replacement-key  =  variant-id ";" absoluteURI

  The variant-id element of the replacement key is the variant-id
  value in the Cval [#VID?#] header of the response, if a Cval header
  which such a value is present, and an empty string otherwise.  The
  absoluteURI element of the replacement key is the absolute URI given
  in, or derived from, the Content-Location header of the response if
  present, and and an empty string if no Content-Location header is
  present.

  If a response from a varying resource has the one-character
  replacement key ";", a cache should interpret this as a signal from
  the resource author that storing this particular response in cache
  memory will never lead to a saving of network resources.  If a cache
  has stored in memory a 200 (OK) response with a certain replacement
  key, and receives, from the same resource, a new 200 (OK) response
  which has the same replacement key, this should be interpreted as a
  signal from the resource author that the old response can be deleted
  from cache memory and replaced by the new response.

  The replacement key mechanism cannot cause deletion from cache
  memory of old responses with replacement keys that will no longer be
  used.  It is expected that the normal `least recently used'
  replacement heuristics employed by caches will eventually cause such
  old responses to be deleted.

       Note: Varying resources which use a Vary header to signal
       variance should put a variant-id value in the Cval header to
       supply a replacement key, and should not include a
       Content-Location header.  It is expected that resources using a
       planned content negotiation mechanism will use the Alternates
       header to signal variance, and Content-Location headers to
       supply replacement keys.


[End of document]
Received on Monday, 1 April 1996 14:56:25 EST

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