[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lynx-dev Problem with Redirects

From: Klaus Weide
Subject: Re: lynx-dev Problem with Redirects
Date: Wed, 17 Nov 1999 03:24:19 -0600 (CST)

On Wed, 17 Nov 1999, Sean Lindsay wrote:

> I'm trying to determine the cause of a quirk in Lynx (2.8) where a 302
> header fails to properly redirect Lynx (while working in other browsers).
> The error produced is "Location URL is not absolute", which doesn't seem to
> be documented.
> The header info that produces the error is as follows:
> HTTP/1.1 302 Found
> Date: Tue, 16 Nov 1999 15:21:19 GMT
> Server: Apache/1.3.9 (Win32)
> Content-Location: try.php3
> TCN: choice
> Vary: negotiate
> Location:
> Connection: close
> Content-Type: text/html

I could reproduce this for the current development code, with

        HTTP/1.1 303 See Other.
        Date: Tue, 16 Nov 1999 19:07:31 GMT.
        Server: Apache/1.3.6 (Unix) PHP/3.0.12.
        Content-Location: headline.php3.
        Vary: negotiate.
        TCN: choice.
        Connection: close.
        Content-Type: text/html.

(which is what the URL below actually sends - the differences are
insignificant for Lynx).

> This header is being produced by a server-side PHP script (running on
> Apache), which is sent the redirection URL as a search argument ("?url=").
> The script works fine in other browsers, however Lynx reports the "Location
> URL is not absolute" error, then tries to load the file listed in the
> Content-Location: header.
> A live example of this script in action can be found at:
> (any URL can be substituted in the search argument)
> It would seem that the additional headers in the first example are causing
> problems for Lynx. Unfortunately PHP does not have the ability to remove
> headers from an Apache response, only to add them.
> Can anyone suggest what might be causing this problem, and how I might be
> able to work around it?

It's a real bug in Lynx.

Normally (in non-redirection responses), all headers are parsed the Right
Way (in HTMIME.c).  But for redirections, the code uses a shortcut (in
HTTP.c) that looks only for a few specific headers (Location:, Set-Cookie:,
Set-Cookie2:).  This (for Location:) is the case in all Lynx versions back
to at least 2.5 and 2.4-FM.  It's somewhat surprising that it hasn't caused
known problems earlier.

The shortcut code just scans a buffer (containing the response received)
for an occurrence of the string "Location:" (in a case-insensitive way).
It doesn't check whether that's at the beginning of a line, so your
"Content-Location:" gets erroneously detected as a "Location:".

So we have to fix the parsing in HTTP.c.

As for workarounds (needed anyway for all the existing Lynx copies out
there) - can you somehow suppress generation of the Content-Location
header?  (I assume it is generated by Apache's "negotiation" module,
as would be the 'TCN: choice'.)  Or can you somehow arrange for
"Location:" to appear before "Content-Location:"?

We might also have to ask the Apache developers to add yet another
browser-specific workaround.  (There already is one for Lynx, listed
in <>.)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]