You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Koen Holtman <Ko...@cern.ch> on 1999/01/19 21:15:32 UTC
Apache 1.3.4 <-> Lynx 2.[78] compatibility problem
James A. Treacy <tr...@debian.org> notified me of a compatibility
problem between the Apache 1.3.4 mod_negotiation and Lynx 2.7 and
higher. Lynx has a protocol bug which causes it to interact badly
with the 1.3.4 mod_negotiation. This bug has been present since Lynx
2.7, but only comes to the surface now that Apache implements
transparent content negotiation.
It turns out that lynx versions 2.7 and higher include the header
'negotiate: trans' in their requests. This header (defined in
rfc2295) implies that the sender supports transparent content
negotiation, however lynx does not support transparent content
negotiation. Apache 1.3.4 does, so for negotiated resources it sends
back the correct response for 'negotiate: trans', which always is a
300 response.
The end result for the Lynx user is that any GET on a negotiated page
returns a list of variants, never an actual variant, no matter which
Accept headers are configured. This makes sites which use a lot of
negotiation extremely painful to use from Lynx.
Long term fix:
According to the relevant spec Lynx is wrong and Apache is right.
Lynx should be changed to not send 'negotiate: trans'. According to a
Lynx change log I found (e.g. at
http://www.peru.edu/~kincaid/lynx/html26a.html) the header is being
sent in an attempt to be compatible with some unspecified 1.1 servers,
but the header makes lynx incompatible with servers supporting
transparent content negotiation.
Any comments from Lynx developers?
Short term fix:
I can code up an Apache 'BrowserMatch' special case in mod_negotiation
to work around the Lynx bug. From a recent browser statistics sample
I gather that Lynx users upgrade to a new version only very slowly, so
the 'short term' is at least a year. I think that Lynx is important
enough to warrant the addition of a BrowserMatch. In hits, Lynx has
only a tiny fraction of the browser market, but many people (including
me) use it as a fall-back in strange situations.
Any comments from Apache developers?
Koen.
Re: Apache 1.3.4 <-> Lynx 2.[78] compatibility problem
Posted by Ben Laurie <be...@algroup.co.uk>.
Martin Kraemer wrote:
>
> On Tue, Jan 19, 1999 at 09:15:32PM +0100, Koen Holtman wrote:
> > The end result for the Lynx user is that any GET on a negotiated page
> > returns a list of variants, never an actual variant, no matter which
> > Accept headers are configured. This makes sites which use a lot of
> > negotiation extremely painful to use from Lynx.
>
> Oops! That will bite many european (asian / international / ... )
> users. I'm offering german and english content-language on my servers
> myself, and would hate to go back to "click here for the xyz language"
> kind of "negotiation" because of this bug.
It is actually possible, with some pain, to do both...
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
Re: Apache 1.3.4 <-> Lynx 2.[78] compatibility problem
Posted by Koen Holtman <Ko...@cern.ch>.
On Tue, 19 Jan 1999, Martin Kraemer wrote:
> On Tue, Jan 19, 1999 at 09:54:44PM +0100, Koen Holtman wrote:
> > On Tue, 19 Jan 1999, Martin Kraemer wrote:
> > > What kind of BrowserMatch solution did you have in mind?
> >
> > I had in mind a completly new browsermatch keyword, something like
> >
> > BrowserMatch "Lynx/2\." ignore-negotiate-trans
>
> Yup. That sounds sensible. And I agree that it should be only a few
> lines of patch. Are you going to try and make one?
Yes, but I won't make one this evening. Tommorrow or the day after.
>
> Martin
Koen.
Re: Apache 1.3.4 <-> Lynx 2.[78] compatibility problem
Posted by Martin Kraemer <ma...@mch.sni.de>.
On Tue, Jan 19, 1999 at 09:54:44PM +0100, Koen Holtman wrote:
> On Tue, 19 Jan 1999, Martin Kraemer wrote:
> > What kind of BrowserMatch solution did you have in mind?
>
> I had in mind a completly new browsermatch keyword, something like
>
> BrowserMatch "Lynx/2\." ignore-negotiate-trans
Yup. That sounds sensible. And I agree that it should be only a few
lines of patch. Are you going to try and make one?
Martin
--
<Ma...@MchP.Siemens.De> | Siemens Information and
Phone: +49-89-636-46021 | Communication Products
FAX: +49-89-636-47816 | 81730 Munich, Germany
Re: Apache 1.3.4 <-> Lynx 2.[78] compatibility problem
Posted by Koen Holtman <Ko...@cern.ch>.
On Tue, 19 Jan 1999, Martin Kraemer wrote:
> On Tue, Jan 19, 1999 at 09:15:32PM +0100, Koen Holtman wrote:
> > The end result for the Lynx user is that any GET on a negotiated page
> > returns a list of variants, never an actual variant, no matter which
> > Accept headers are configured. This makes sites which use a lot of
> > negotiation extremely painful to use from Lynx.
>
> Oops! That will bite many european (asian / international / ... )
> users. I'm offering german and english content-language on my servers
> myself, and would hate to go back to "click here for the xyz language"
> kind of "negotiation" because of this bug.
>
> > Short term fix:
> >
> > I can code up an Apache 'BrowserMatch' special case in mod_negotiation
> > to work around the Lynx bug.
>
> Hmmm. How could that work? Going back to HTTP/1.0 level won't help.
> (For instance, X-Mosaic is HTTP/1.0, can send Accept-Language headers,
> but it doesn't understand a 300 reply. AFAIK the Apache negotiation code
> makes no distinction between HTTP protocol levels as long as the
> Accept-* headers are present).
The 1.3.4 code will only send a 300 to clients which claim to support
transparent content negotiation. All others get a 406 with the same
headers and entity body.
>
> What kind of BrowserMatch solution did you have in mind?
I had in mind a completly new browsermatch keyword, something like
BrowserMatch "Lynx/2\." ignore-negotiate-trans
with code to match in mod_negotiation.c. I need to think a bit about the
cache correctness implications but overall it should be fairly trivial to
implement.
>
> If such a "short term" solution was possible, I'd +1 the integration
> of that workaround into the standard config files.
>
> Martin
Koen.
Re: Apache 1.3.4 <-> Lynx 2.[78] compatibility problem
Posted by Martin Kraemer <ma...@mch.sni.de>.
On Tue, Jan 19, 1999 at 09:15:32PM +0100, Koen Holtman wrote:
> The end result for the Lynx user is that any GET on a negotiated page
> returns a list of variants, never an actual variant, no matter which
> Accept headers are configured. This makes sites which use a lot of
> negotiation extremely painful to use from Lynx.
Oops! That will bite many european (asian / international / ... )
users. I'm offering german and english content-language on my servers
myself, and would hate to go back to "click here for the xyz language"
kind of "negotiation" because of this bug.
> Short term fix:
>
> I can code up an Apache 'BrowserMatch' special case in mod_negotiation
> to work around the Lynx bug.
Hmmm. How could that work? Going back to HTTP/1.0 level won't help.
(For instance, X-Mosaic is HTTP/1.0, can send Accept-Language headers,
but it doesn't understand a 300 reply. AFAIK the Apache negotiation code
makes no distinction between HTTP protocol levels as long as the
Accept-* headers are present).
What kind of BrowserMatch solution did you have in mind?
If such a "short term" solution was possible, I'd +1 the integration
of that workaround into the standard config files.
Martin
--
<Ma...@MchP.Siemens.De> | Siemens Information and
Phone: +49-89-636-46021 | Communication Products
FAX: +49-89-636-47816 | 81730 Munich, Germany