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 01:30:33 GMT
> 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.

I am in favor of giving people as much rope as possible to hang themselves,
provided that people who care about being hanged or not are informed of
how to avoid it, and that people are not hanged by default. In other words,
my vision of a valid HTTP server is one that is valid by default and
provides the user with every option needed to remain valid, but doesn't
necessarily force the user to do only valid things.

Thus, my requirement for request-header case features is that they sustain
the connection between the options/envars being set and what request headers
are looked at to determine if that option is set.  This allows any piece
of the server that selects content based on that option to also set the
Vary header field according to how that option might be determined.

Unfortunately, I have no recommendation on how to do that in general.
I do like the notion of a generic <Header> (actually, <Request-Header>
would be better) feature and would prefer that over BrowserMatch if it
supported the requirement stated above.

OTHER outstanding issues:

   There are a couple on the bugdb list.

   I need to fix the handling of IMS and IUS in http_protocol.c to
   use the new date routines instead of later_than.  I should be able
   to do that tonight if nothing else comes up.


View raw message