httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Koen Holtman <>
Subject Re: [PATCH] Apache 1.3.4 <-> Lynx 2.[78] compatibility problem
Date Fri, 22 Jan 1999 08:53:59 GMT

On Thu, 21 Jan 1999, Roy T. Fielding wrote:

> >Here is an Apache 1.3.4 patch for the 'short term fix' of the apache <->
> >lynx problem which I described earlier.
> BrowserMatch is an expensive process and requires everyone using negotiation
> to modify their config files.  A bug that isn't likely to occur in multiple
> agents should just be a hardcoded workaround.  

Hard-coding it is OK with me.

>  Also, this type of variance
> does not need the addition of Vary.

But it *does* require the addition of Vary.  Either that, or make the
workaround response uncachable to 1.x proxies (it will be cachable to 1.1
proxies if mod_expires is used, or some other mechanism which adds
cache-control max-age).

Consider a shared 1.1 proxy which understands Vary, and which is shared by
a Lynx needing the workaround and another user agent which sends
negotiate: trans and really means it.  If Lynx sends the request

GET /blah HTTP/1.1
negotiate: trans
accept-language: en

and gets the (woraround) response

HTTP/1.1 200 OK
Vary: negotiate, accept-language
Location: blah.en.html

then this response will be cached in the proxy, and if the other user
agent does the same request, the same response will be returned by the
proxy, which is a TCN protocol violation because if you send 'negotiate: 
trans' on a negotiated resource you are asking for the 300 response and
nothing else.

You may ask why the other agent would bother to send an 'accept-language: 
en' when it always wants a 300 but it could do this to get good results on
servers/cgis not using TCN.

> I'll put in a hardcoded workaround based on your patch.
> ....Roy


View raw message