[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: http://www.foo.com/
> 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.
Location: http://www.foo.com.
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:
> http://www.disabilitytimes.com/go/headline?url=http://www.foo.com
> (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 <http://www.apache.org/docs/misc/known_client_problems.html>.)
Klaus