httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremie Miller <>
Subject Re: outstanding issues for 1.2 code freeze.
Date Tue, 05 Nov 1996 06:18:03 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.

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

	"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: *?

There should probably be a better way to handle Vary for the core code 
and for the modules.

Mabye I am just tired...

Jeremie Miller

On Mon, 4 Nov 1996, Alexei Kosut wrote:

> On Mon, 4 Nov 1996, Roy T. Fielding wrote:
> > > +1. Note that, as Roy said, Vary headers MUST be sent (or we ain't 1.1
> > > compliant). This is a little more subtle than meets the eye, as we have to
> > > send Vary even for things that _don't_ match. I'm prepared to put a bit of
> > > thought into making this as easy as poss for modules if there is consensus
> > > proceed. Also note that BrowserMatch as it stands makes us noncompliant with
> > > 1.1, so I guess we have to do something.
> > 
> > Not too easy -- you don't want to send Vary at all unless the actual content
> > of the response might change in a way that affects caching.  Something like
> > nokeepalive or denying bad robots does not qualify.
> Precisely. Which is why I didn't have mod_browser send a "Vary:
> User-Agent" header - because it sets the env variable for every darn
> request, and for the use for which it was originally intended (I wrote
> the module while employed by Organic Online, for them), the content
> which was generated based on the User-Agent string (server-parsed HTML
> files) would be uncacheable by its very nature anyway, so I didn't
> worry about it too much. If we extend the functionality,
> unfortuantely, we have to start worrying about it. In other words,
> when all a header can do is set an env variable, it's not a big deal,
> because the only things that can use env variables are CGI scripts and
> (X)SSI documents, which are generally uncacheable. Anyone who has a
> custom module that also uses them presumable knows what they're
> doing. That's the rationale for mod_browser not setting Vary.
> But when you allow things like
> <Header User-Agent ~Mozilla/.*>
> Alias /generic-images /netscape-images
> </Header>
> (to use a stupid example), then you open up a whole realm of
> cacheability questions. Methinks this should be shunted to 2.0.
> -- 
> ________________________________________________________________________
> Alexei Kosut <>      The Apache HTTP Server
> URL:

View raw message