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

[Koen Holtman]

On Tue, 19 Jan 1999, Klaus Weide wrote:

[...]
> I don't know what those unspecified servers are/where, and agree that
> Lynx shouldn't send that header.
[...]
> So this should change immediately in the current Lynx development code.

OK.

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

Coping with user-modified User-Agent strings can be tricky, and cannot
really be reconciled with trying to limit the range of lynx version
numbers. 

Luckily, a possible future Lynx version which *does* implement transparent
content negotiation is not very likely to send 'negotiate: trans', it will
more likely send 'negotiate: 1.0' or 'negotiate: vlist'.  So I plan to do
the following:

  - match on plain 'Lynx'
  - but only enable the bug workaround if the Negotiate header has 'trans'
    as the exact contents.

In the unlikely case that a future transparent content negotiation
implementation in Lynx would need to get the exact effect of sending
'negotiate: trans', then it could send something like 'negotiate: trans,
trans' to bypass the bug workaround.  (Saying 'trans' twice is
semantically equivalent to saying it only once.)

>     Klaus

Koen.