httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@liege.ICS.UCI.EDU>
Subject Re: outstanding issues for 1.2 code freeze.
Date Wed, 06 Nov 1996 02:07:32 GMT
> OK, after a glance at HTTP/1.1, focusing on the Vary parts and the statement:
> 	"An HTTP/1.1 server MUST include an appropriate Vary header field with
> 	any cachable response that is subject to server-driven negotiation."
> Unless I am missing something, three things need to be answered first, 
> "appropriate Vary header field", "cachable response", and "subject to
> server-driven negotiation".
> I am no expert, but these are my first reactions:
> 	"appropriate Vary header field"
> All of the headers that in _any_ way played a part in determining the data 
> being returned.

Almost. It is all of the header fields that may cause one representation to
be chosen instead of some other representation (which means no header fields
in the case where there is only one representation, and "*" in severe cases
like /cgi-bin/test-cgi).

> 	"cachable response"
> Any response that would be identical to another response(as far as the 
> server knows at least).

No, cachable is defined by the spec. It means a GET response which is not
marked as non-cachable by Expires and/or Cache-Control, or any other response
which is marked as cachable by Expires and/or Cache-Control.

> 	"subject to server-driven negotiation"
> I would suppose this is any response that may be different based on any 
> headers in the request(or network address).


> Unless I am missing something, this would include Host: Referrer: 
> User-Agent: and others not handled by mod_negotiation.  Doesn't that mean 
> the VirtualHost code needs to return a Vary: (because of the Host:) as well 
> as any other code that uses any of the headers?  And for non-header based 
> negotiation (allow/deny) it would return a Vary: *?

Referer does not normally modify the response content. User-Agent only applies
if the code is doing selection based on User-Agent. allow/deny is not
negotiation -- it is authentication, which is not normally cachable
(or at least it shouldn't be unless you don't care about proxies giving
the response to anyone).  Adding Host is necessary for URLs that are
available on more than one virtual host (like /), since a server-side cache
would need to know that in order to correctly cache those resources.
The VirtualHost code should indeed be appending Vary: Host to the response
if it is doing an internal redirect based on Host.


View raw message