Re: lynx-dev Apache 1.3.4 <-> Lynx 2.[78] compatibility problem

[Klaus Weide]

On Tue, 19 Jan 1999, Koen Holtman wrote:

> James A. Treacy <address@hidden> 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?

I don't know what those unspecified servers are/where, and agree that
Lynx shouldn't send that header.  If there was a problem with some
servers sending 406 when a non-error response would be more desirable,
and that problem was really alleviated by sending the header, then
that problem may have gone by now.  Also the only dimensions of negotiation
for which that problem seems possible seem to be Accept-Language and
Accept-Charset, and then only if Lynx has explicitly been configured
for a preferred language or charset, and in that case the user can
usually undo the explicit setting at the Options screen, after seeing
the 406 response text.

So this should change immediately in the current Lynx development code.

As for the compatibility fix for Apache suggested (below): if that is
done, it should be done in a way that doesn't prevent negotiation from
working right if/when some future Lynx version supports transparent
negotiation (and really means the header it sends).  So it should match on
something like "Lynx.2.[78]" or "Lynx.(7|8([^.]|\.[12]))", the latter
allows for the possibility that that hypothetical version might be
Lynx/2.8.n with n > 2.  It would be desirable to make the regex as liberal
as possible (no "^", using "." instead of "/" and "\." for example, using
NoCase match), since many Lynx users modify the User-Agent string to get
around graphics-only bias, so that "lynx" may appear in a ( comment ) and
may not have exactly the right punctuation.


    Klaus

> 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.