- From: Larry Masinter <masinter@parc.xerox.com>
- Date: Thu, 25 Jan 1996 00:09:13 PST
- To: drtr1@cus.cam.ac.uk
- Cc: mogul@pa.dec.com, http-caching@pa.dec.com
> Vary = "Vary" ":" 1#varying
> varying = http-name | "{" vary-parm "}"
> http-name = token
> vary-parm = "const" | "unknown" | extension-parm
> extension-parm = token
> http-name is the field-name for an HTTP General-Header, Request-Header or
> Entity Header whose field-value contains the parameter affecting the document.
Not all general, request, or entity headers are candidates for
varying, are they? Date:? Also, when the same transaction includes a
request and a response, is it the response value or the request value
that determines the variation?
Don't the field names always correspond to the the request's headers
(either sent or defaulted) and not the responses?
> The definition of
> `semantically different' must be specified with the definition of each
> parameter.
Where can we find this specification? Should it be in the HTTP/1.1
draft? Isn't this a relationship other than 'different', that is 'not
inclusive'? I.e., if the response varies on accept-language and the
cached response response was content-language: en_us, shouldn't it
also match an accept-language en?
> 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 use a direct comparison
> of the octets comprising the parameter values for equality testing.
You need a different terminology than 'cache' to designate the caching
agent.
I'm uneasy about the { extension } parameter, without some registry of
such things and a mechanism for telling whether the parties exchanging
one have the same interpretation.
Received on Thursday, 25 January 1996 08:39:53 UTC