- From: Koen Holtman <koen@win.tue.nl>
- Date: Mon, 20 May 1996 00:06:35 +0200 (MET DST)
- 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.
Koen.
---snip---
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
| (VARIANT) IT BINDS TO A GENERIC RESOURCE. SUCH AN assignment can only
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.
| [#NEXT TWO PARAGRAPHS MERGED TO ELIMINATE BAD CASE OF COMMITTEE-TALK#]
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
unconditional.
| 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
used.
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
| EXACT RULES.)
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
| CONFUSION THAN CLARITY.#]
The cache SHOULD use the new response to reply to the current request.
| It may insert it into cache STORAGE. [#SENTENCE PART that DIRECTLY
| CONTRADICTS the VARY HEADER SECTION DELETED#] If it inserts the new
response into cache storage it should follow the rules in section
16.4.3.
---------------
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
server.
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
| the RESOURCE ENTITY.
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
response.
| [#LOTS OF OCCURENCES OF `200 (OK) RESPONSE' CHANGED TO `RESPONSE'
| BELOW, IN ORDER TO MATCH TERMINOLOGY WITH THE CACHING SECTION.#]
| 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 UTC