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

v11-03 COMMENT: Generic resources, various edits

From: Koen Holtman <koen@win.tue.nl>
Date: Mon, 20 May 1996 00:06:35 +0200 (MET DST)
Message-Id: <199605192206.AAA08372@wswiop05.win.tue.nl>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

I have noticed several errors in various v11-03 sections about generic
resources.  The sections involved are

  16.5 Caching and Generic Resources  
  16.7 Selecting a Cached Response
  16.13 Cache Replacement
  18.46 Vary .

I have included corrected text for these sections below. This text has
computer generated change bars and typesets all words that were added
in uppercase.  Some comments appear between [# ... #].

As a side remark: these sections contain a lot of redundancy.  I have
only edited for correctness, not for style or length.  I have some
plans to do a length-reducing editing pass on these sections next
week.  Larry Masinter remarked last month that most of the generic
resource material that is now in 18.46 (Vary) should really be in the
caching section.



  16.5 Caching and Generic Resources

  Generic resources interacts with caching in several ways:

    .  A generic resource (one subject to content negotiation) may be
|      bound to more than one RESOURCE entity. Each of these RESOURCE
       entities is called a "variant" of the resource.

    .  The request-URI may be only one part of the cache key.

  16.5.1 Vary Header Use

| Origin servers may respond to requests for generic resources USING the
  Vary header (see section 18.46 for a full description) to inform the
  cache which header fields of the request were used to select the
  variant returned in the response. A cache can use that response to
  reply to a subsequent request only if the two requests not only
  specify the same URI, but also have the same value for all headers
  specified in the Vary response-header.

  The Vary header may also inform the cache that the variant was selected
  using criteria not limited to the request headers; in this case, the
  response MUST NOT be used in a reply to a subsequent request except if
  the cache relays the new request to the origin server in a conditional
  request, and the origin server responds with 304 (Not Modified) and
  includes the same variant-ID (see 13.8.3).

  16.5.2 Alternates Header Use

  The Alternates header is present in the HTTP/1.1 to enable caching of
  entities from the planned content negotiation facilities. If a cache
  receives an Alternates header in a response from the origin server
| (and DOES NOT implement these planned facilities), it should act as if
  the response carried a "Vary:{accept-headers}" header.  This means
  that the response may be returned in reply to a subsequent request
| with ACCEPT headers identical to those in the current request.

  16.5.3 Variant-ID Use

| An origin server SHOULD ASSIGN a variant-ID to each resource entity
  be made by the origin server. It then returns the appropriate
  variant-ID with each response that applies to a specific resource
  entity (variant), using the ETag header (see Error! Reference source
  not found.).

  When sending an entity derived from a particular variant in a response,
  an origin server SHOULD include a variant-ID identifying the variant in
  the ETag header (see section Error! Reference source not found.).  This
  variant-ID can be used for cache replacement and in conditional requests
  on the generic resource. When a cache receives a successful response
  with a variant-ID, it SHOULD use this information to replace any
  existing cache entries for the same variant of the corresponding URI.
  That is, it forms a cache key using the URI of the request and the
  variant-ID of the response. If this key matches the key of an existing
  cache entry, it SHOULD replace the existing entry with the new response
  (subject to all of the other rules on caching). See section Error!
  Reference source not found. for more details on update.


  When a cache performs a conditional request on a generic resource, and
  it has one or more cache entries for the resource that include variant-
| IDs, the cache CAN transmit the (cache-validator, variant-ID) tuples in
  the conditional request, using the variant-set mechanism (see section
  7.13). This tells the server which variants are currently in the
  requester's cache.

| When a server receives a conditional request that includes a variant-
  set, and the server is able to reply with an appropriate variant (either
  because it is the origin server, or because it is an intermediate cache
| that can properly implement the CONTENT NEGOTIATION algorithm), once it
  has selected the variant it should examine the elements of the supplied
  variant-set. If one of these matches the variant-ID of the selected
  variant, and if the cache validators match, the server SHOULD reply with
  a 304 (Not Modified) response, including the variant-ID of the selected
  variant. Otherwise, the server should reply as if the request were

| The ORIGIN server may optionally use the variant-set information in its
  selection algorithm. For example, if the selection algorithm yields
  several variants with equal preference, and one of these is already in
  the requester's cache, the server could select that variant and avoid an
  extra data transfer. This is a performance optimization; otherwise, the
| CONTENT NEGOTIATION mechanism is orthogonal to the variant-ID mechanism.


  16.7 Selecting a Cached Response

  When a cache receives a request it tries to see if it has a cached
  response appropriate for that request, using the matching rules in this
  section. If such a response exists, then the cache can decide if it is
  fresh enough (using the expiration model in section 16.1.2 and the
  freshness requirements of client and origin-server expressed in the
  Cache-Control headers of the request and cached response) to return in
  reply to the request.

  If on a cache lookup there are two or more fresh entries that appear to
  match the request, then the one with the most recent Date value MUST be

  16.7.1 Plain Resources

  If the cached response was for a plain resource (that is, the response
  includes no Vary or Alternates headers), it matches if the Request-URI
  of the request matches the Request-URI of the of the request that caused
  the cached response to be stored. Request-URIs match if their canonical
  forms (see section 7.2.3) are equal.

  16.7.2 Generic Resources

  If the cached response was for a generic resource (that is, the response
  includes Vary, or Alternates headers), it matches if the Request-URI of
  the request matches the Request-URI of the request that caused the
  cached response to be stored, and the selecting request header field
  values of the request match those of the request that caused the cached
| response to be STORED OR REVALIDATED. (See section 18.46 on VARY for

  If the response contains "Vary: {other}", then the selecting request
  header field values for its request are defined as never matching a set
  of request headers.


  16.13 Cache Replacement

  If a new cacheable response (see sections 18.10.2, 16.2.6, 16.2.8 and
  16.8) is received from a plain resource while any existing responses for
  the same resource are cached, the cache MUST NOT return any of those
  older responses to any  future requests for the resource.

    Note: a new response that has an older Date header value than
    existing cached responses is not cacheable.

  If a new cacheable response is received from a generic resource with a
  certain variant-ID while any old responses with the same variant-ID for
  the same resource are cached, the cache MUST NOT return any of those old
  responses to any future requests for the resource.

|   Note: The cache CAN delete the old response(s) from cache storage to
|   recover space.  [#REST OF note DELETED, it WOULD cause MORE

  The cache SHOULD use the new response to reply to the current request.
| It may insert it into cache STORAGE. [#SENTENCE PART that DIRECTLY
  response into cache storage it should follow the rules in section


  18.46 Vary

  The Vary response-header field is used by an origin server to signal
  that the resource identified by the current request is a generic)
| resource.  A generic resource has multiple RESOURCE entities
  associated with it, all of which are representations of the content of
  the resource.  If a GET or HEAD request on a generic resource is
| received, the origin server will select one of the associated RESOURCE
  entities as the entity best matching the request.  Selection of this
  entity is based on the contents of particular header fields in the
  request message, or on other information pertaining to the request,
  like the network address of the sending client.

  A resource being generic has an important effect on cache management,
  particularly for caching proxies which service a diverse set of user
| agents.  All SUCCESFUL (2XX) responses from generic resources MUST
  contain at least one Vary header (section 18.46) or Alternates header
  (section 18.8) to signal variance.

  If no Vary headers and no Alternates headers are present in a
| SUCCESSFUL response, then caches may assume, as long as the response
  is fresh, that the resource in question is plain, and has only one
| associated RESOURCE entity.  Note however that this RESOURCE entity
  can still change through time, as possibly indicated by a
  Cache-Control response header (section 18.10).

| After selection of the RESOURCE entity best matching the current
  request, the origin server will usually generate a 200 (OK) response,
  but it can also generate other responses like 206 (Partial Content) or
  304 (Not Modified) if headers which modify the semantics of the
  request, like Range (section 18.38) or If-Match (section 18.26), are
| present.  An origin server need not be capable of selecting A RESOURCE
  entity for every possible incoming request on a generic resource; it
  can choose to generate a 3xx (redirection) or 4xx (client error) type
  response for some requests.

  In a request message on a generic resource, the selecting request
  headers are those request headers whose contents were used by the
| origin server to select the RESOURCE entity best matching the
  request. The Vary header field specifies the selecting request headers
  and any other selection parameters that were used by the origin

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

         selection-parameter  = request-header-name
                              | "{accept-headers}"
                              | "{other}"
                              | "{" extension-parameter "}"

         request-header-name  = field-name

         extension-parameter  = token

  The presence of a request-header-name signals that the request-header
  field with this name is selecting.  Note that the name need not belong
  to a request-header field defined in this specification, and that header
  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

    Note: This specification allows the origin server to express that
    other parameters were used, but does not allow the origin server to
    specify the exact nature of these parameters.  This is left to
    future extensions.

  If an extension-parameter unknown to the cache is present in a Vary
  header, the cache MUST treat it as the "{other}" parameter. If multiple
  Vary and Alternates header fields are present in a response, these MUST
  be combined to give all selecting parameters.

  The field name "Host" MUST never be included in a Vary header; clients
  MUST ignore it if it is present.  The names of fields which change the
  semantics of a GET request, like "Range" and "If-Match" MUST also never
  be included, and MUST be ignored when present.

  Servers which use access authentication are not obliged to send "Vary:
  Authorization" headers in responses.  It MUST be assumed that requests
  on authenticated resources can always produce different responses for
  different users.  Note that servers can signal the absence of
  authentication by including "Cache-Control: public" header in the


| A cache MAY store and refresh SUCCESSFUL responses from a generic
| resource according to the rules in section 16. 

  When getting a request on a generic 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 generic 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 If-NoneMatch
  header listing the etag-info values in the ETag headers (section Error!
  Reference source not found.) of the cached responses which have variant-
  IDs.  If it then gets back a 304 (Not Modified) response with the etag-
| info of a cached response in its ETag header, it can return
| this cached response to its client, after merging in any of the
  304 response headers as specified in section 16.4.2.

  Second, if a cache gets a request on a generic resource, it can return
| to its client a cached, fresh 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 304 (Not Modified) response
       which had the same etag-info value in its ETag header as the
|      cached, fresh 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.

| If a cached response MAY be returned to a request on a generic
  resource which includes a Range request header, then a cache MAY also
| use this response to construct and return a 206 (Partial
  Content) response with the requested range.

    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 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.
Received on Sunday, 19 May 1996 15:07:58 EDT

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