Re: LYNX-DEV Bug in Lynx 2-7-2 with web500gw

[Foteos Macrides]

Ric Miller ACNS <address@hidden> wrote:
>>[...]
>> If you set it to that which was used for v2.5 you will get back
>> the HTML which v2.5 is sent, which further indicates that the User-Agent
>> header is affecting what HTML that server returns.  
>
>  Gee, I set the User-Agent header to the exact header at 2.5 and it is
>  still not returning the same html.  This seems to indicate that the
>  server is not responsible for the problem.
>
>> But there is no way
>> to know for sure, and to assess whether it's a bug or feature of the server,
>> without looking at its code.  
>
>  Or a bug or feature of the client.

        The User-Agent header value for v2.5 was "Lynx 2.5 libwww-FM/2.14".
The slash between "Lynx" and "2.5" was missing (due to a typo in LYMain.c).
When I make that the User-Agent header value sent by v2.7.2, I get back
HTML which positions the form markup at the top of the page.  Without
that slash, the user agent is "Lynx 2.5 libwww-FM" (everything up to the
first slash) instead of "Lynx".  If I use "Lynx/#.# libwww-FM/2.14" so
that the value indicates "Lynx" as the user agent, I get back HTML which
positions the form markup at the bottom of the page.  The actual version
number doesn't matter, just that a slash appears immediately after "Lynx".
I get the same difference in returned HTML and its positioning of the
form markup if I use:  Lynx 2.7.2 libwww-FM/2.14
              versus:  Lynx/2.7.2 libwww-FM/2.14
                           ^
The client (Lynx) correctly positions the form text-input, submit, and
reset fields at the top or botton depending on which HTML document is
returned.  The "correct" positioning of them is dependent on the
markup, and thus at the top or bottom, depending on which of the two
documents is received.  Look at the actual source returned for the
two cases, and compare where the form markup is positioned.

        Because the positioning of the form markup in the two documents,
and other content in them, do not differ in ways that would matter for
GUI versus text browsers, I doubt that it reflects a feature for the
server, but rather a problem in its parsing of HTTP headers.  But one
would have to look at the server's code to be sure.

                                Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 address@hidden         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================