LYNX-DEV Handling of URL fragments received in 302 Location: header

[Al Gilman]

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.

I think that Klaus and Fote have discussed this issue and I
haven't entirely followed the discussion.

We can tell Readers Digest to send an absolute URL in the 302 and 
they can serve Lynx users that have current software.  Did anyone
hear back from the HTTP authorities on the interpretation of 
URL fragments offered in a Location: header?

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

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.

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