Re: LYNX-DEV Redirection problem with relative URL

[Klaus Weide]

[ problems with http://www.readersdigest.com ]

On Sat, 12 Jul 1997, Al Gilman wrote:

> On webwatch-l we have been looking into why Lynx has trouble
> accessing the Readers Digest site.  It turns out that the site is
> returning a 302 message with a Location: header containing what
> would be a correct relative URL if the Location: of the GET
> request to which the 302 is replying is treated as establishing a
> BASE for its resolution.
[...]
> We can tell Readers Digest to send an absolute URL in the 302 and 
> they can serve Lynx users that have current software.

Yes, you should do that.  Then all users with software which follows
the standards in this area can access the site, not just those with
software which has the right error recovery heuristics.

> Did anyone
> hear back from the HTTP authorities on the interpretation of 
> URL fragments offered in a Location: header?

This has nothing to do with "fragments" - there is no '#' character
involved.  I don't think there was any discussion (on lynx-dev) of fragments
in connection with Location headers.

(If you are interested in that other discussion you are probably referring to,
you can find relevant messages in
<URL:ftp://services.bunyip.com/pub/mailing-lists/uri.archive/uri.archive.9705>
[it is a big mailbox file].)

> The language in the 302 paragraph, viz:
> 
> --------------------------quote---------------------------------------
> 
>    If the new URI is a location, its URL SHOULD be given by the Location
>    field in the response. Unless the request method was HEAD, the entity
>    of the response SHOULD contain a short hypertext note with a
>    hyperlink to the new URI(s).
> 
> ------------------------end quote-------------------------------------
> 
> leaves itself open to the interpretation that the URL could be a
> relative URL (if such a beast made sense in this context).

Read section 14.30 of RFC 2068.  There is no ambiguity there.  "The field 
value [of the Location header] consists of a single absolute URL."

> I have experienced failure-recover behavior from Lynx when a relative
> URL is used in redirection-via-refresh but there was no failure-recover
> attempted with 2.7 or 2.7.1 so far as we can tell in this 302 case.

HTTP: Picked up location '/*TEMPLATE=:address@hidden'
HTAccess:  status=29996
HTAccess: 'http://www.readersdigest.com/' is a redirection URL.
HTAccess: Redirecting to '/*TEMPLATE=:address@hidden'
Using /*TEMPLATE=:address@hidden
Alert!: Unsupported URL scheme!

The problem is the presence of the ':' character, which makes Lynx try
to interprete this as an absolute URL for a "/*TEMPLATE=" scheme instead
of a relative URL (after all, an absolute URL is what should be there).
This should be improved in Lynx, but it would be much better if the
site would send a valid absolute URL in the first place.

   Klaus




;
; To UNSUBSCRIBE:  Send a mail message to address@hidden
;                  with "unsubscribe lynx-dev" (without the
;                  quotation marks) on a line by itself.
;