Re: Vary VS URI with an eye towards caching

Firstly, apologies for my terse message.
Here is a fuller description of the Vary header.

  David Robinson.

1. Variant URLs and Parameters

   Increasing use is being made of `variant' URLs; these are URLs which
   provide different documents to the client depending on the exact
   circumstances of the request. Principally this is a dependence on the
   headers sent by the client, although it could be a dependence on other
   parameters of the request, such as those defined at the transport
   level. (The client IP address is one example of such a parameter.)

   A parameter is defined as that feature of the request which affects
   the document returned by the server. Parameters may be encoded in the
   HTTP header information supplied by the client, but a parameter does
   not necessarily refer to a complete HTTP header.

   Note that URLs which vary with time or internal server state are not
   considered to be variant URLs, as _all_ URLs are expected to vary
   with time or server state. Thus a URL is considered to be variant if
   two different access at a particular instant would return different
   documents.

2. Caching of variant URLs

      [What happens currently with HTTP/1.0? I believe that caches
       can not and do not take account of variant URLs.]

   It is important that caches do not obstruct the servers use of
   variant URLs (as almost certainly happens at present). Thus there is
   a need to inform the cache of the variance of a URL.

   Also, variant URLs are almost as `cacheable' as non-variant URLs.
   Firstly, because the most common use of caching is by browsers on a
   per-user basis; repeat requests from the same user with the same
   browser are very likely to result in the same variant being sent by
   the server. Secondly, because the most common implementation is by
   the server selecting one of a small group of documents; the cache
   could usefully cache all the possible variants.

   Thus the information provided to the cache should also improve the
   cacheability of variant URLs, as well as simply enabling their use
   through caches.

   The simplest approach is for the server to indicate which parameters
   affect the document. More complicated would be detailing a complete
   prescription for the algorithm the server uses to produce the
   document.

3. The Vary header

3.1 Rationale

   The Vary header implements the simplest option. It is based on the
   observation that equating parameters with HTTP header values is
   simple to implement and should provide sufficient information for the
   most common uses.

3.2 Syntax

      Vary           = "Vary" ":" 1#varying
      varying        = vary-name * ( ";"  option)
      vary-name      = http-name | "{" extension-vary "}"
      http-name      = token
      extension-vary = token
      option         = attribute "=" value
      attribute      = token
      value          = token | quoted-string

   http-name is the field-name for an HTTP General-Header,
   Request-Header or Entity Header which contains the parameter
   affecting the document. extension-vary is an identifier of a
   parameter affecting the document which is not contained in an HTTP
   header; no extension-vary values are defined here. They are provided
   for future enhancement. The "{" and "}" are required to distinguish
   extension-vary values from field-names for HTTP extension-headers.

   'option' provides more information how the parameter is contained
   within the feature identified by vary-name; options are specific to
   each vary-name. None are defined here; they are provided for future
   enhancement.

3.3 Use

   The Vary header describes which parameters of the request affect the
   document returned by the server. The identification of a parameter
   indicates that different requests with semantically different values
   for the parameter may result in differing documents being returned by
   the server. The definition of `semantically different' should be
   specified with the definition of each parameter. If a cache cannot
   determine that two named parameter values are not semantically the
   same, then it should not return the response provide for one value of
   the parameter to a request with the other value of the parameter. In
   the absence of any information about the semantics of the parameter,
   the cache should do a direct comparison of the octets comprising the
   parameter values.

   If the Vary header is not supplied, then the cache is provided with
   no information about the variance of the document. For a 200
   response it should assume that the document does not have variants,
   unless a URI header is supplied.

   If the Vary header is supplied by the server, then it should be
   complete.

   Given sufficient information, the cache may use a more sophisticated
   algorithm for equality testing than simple octet comparison. For
   example, for parameters which are whole HTTP headers, the
   'implied *LWS' rule means that spaces between tokens can be ignored.

3.4 HTTP considerations

   Error responses

      Vary headers may be used for unsuccessful responses, where the
      default caching assumption of HTTP/1.0 may be to assume variance.

   Host header

      The document is assumed to always vary with the Host header, and
      so this need not be included in the Vary header.
      
   URI header

      If a URI header and a Vary header are both supplied, then the
      Vary header must include any variant parameters identified by the
      URI header. However, the cache may use the information in the URI
      header to refine its equality testing of parameters.

Appendices

   These appendices are provided for informational reasons only.

A. Sample use of 'option'

   The option to a vary-name further identifies the parameter which
   affects the document returned by the server. For example, if the
   document varies with the Accept-Charset, but only depending on
   whether "iso-8859-1" and "unicode-1-1" are or are not contained in
   the header then

      Vary: Accept-Charset ; exist="iso-8859-1" ; exist="unicode-1-1"

   could be returned to indicted that the document does not depend on
   the presence or absence of any other character set name in the
   Accept-Charset header.

   If this option is needed, then it may reflect a poorly designed
   HTTP header.

B. Sample use of `extension-vary'

   The `extension-vary' syntax could be defined to identify other
   parameters; for example

      Vary: {bandwidth}

   would indicate that the document returned by the server depends on
   the bandwidth to the client.

Received on Friday, 12 January 1996 18:41:36 UTC