Re: outstanding issues for 1.2 code freeze.

["Roy T. Fielding" <fi...@liege.ICS.UCI.EDU>]

>>   1) Generalization of BrowserMatch to apply to any header.
> 
> +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 to
> 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.

> BTW, Roy, it occurs to me that a change of server configuration can break
> caches (by changing what we Vary over and probably other ways). Perhaps we
> should include the date of config files (including .htaccess) as part of the
> ETag?

No, don't worry about it.  Vary and ETags are optimizations to improve the
delivery of cached entities.  The likelihood that a change in config files
would significantly affect an already-cached response's validity is so
small that it would never justify stat'ing all of the config files on
every request.

There is no such thing as a perfect cache, but that doesn't mean they
can't be correct 99.9999999% of the time.

......Roy

Re: outstanding issues for 1.2 code freeze.

[Jeremie Miller <jm...@subcellar.mwci.net>]

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
jmiller@mwci.net


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 to
> > > 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 <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
> URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/
> 
> 

Re: outstanding issues for 1.2 code freeze.

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

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 to
> > 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 <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/