Re: lynx-dev base href -- how generated by Lynx?

[Leonid Pauzner]

2-Mar-2003 13:13 Thomas Dickey wrote:
> On Sun, Mar 02, 2003 at 12:49:40PM -0500, William December Starr wrote:

>> Does anyone have an answer to my original question, i.e., which
>> version of Lynx -- 2.7.1 or 2.8.4rel.1 -- is (well, now it's 'was')
>> producing the correct default base href?  (And why?)

> that I'm not sure of.  Seeing how the content location was (mis)handled, I
> thought it was that lynx is paying attention to this while some other browsers
> are not.  (I saved the trace anyway, to help in constructing a comparable test
> page).  The earlier discussion on content location focused on the fact that
> the data given by the server was incorrect.

According to HTTP/1.1, server is broken and lynx 2.8.4 is correct:

"Future requests MAY specify the Content-Location URI as the request-URI..."


RFC 2616                        HTTP/1.1                       June 1999


14.14 Content-Location

   The Content-Location entity-header field MAY be used to supply the
   resource location for the entity enclosed in the message when that
   entity is accessible from a location separate from the requested
   resource's URI. A server SHOULD provide a Content-Location for the
   variant corresponding to the response entity; especially in the case
   where a resource has multiple entities associated with it, and those
   entities actually have separate locations by which they might be
   individually accessed, the server SHOULD provide a Content-Location
   for the particular variant which is returned.

       Content-Location = "Content-Location" ":"

                         ( absoluteURI | relativeURI )

   The value of Content-Location also defines the base URI for the
   entity.

   The Content-Location value is not a replacement for the original
   requested URI; it is only a statement of the location of the resource
   corresponding to this particular entity at the time of the request.
   Future requests MAY specify the Content-Location URI as the request-
   URI if the desire is to identify the source of that particular
   entity.

   A cache cannot assume that an entity with a Content-Location
   different from the URI used to retrieve it can be used to respond to
   later requests on that Content-Location URI. However, the Content-
   Location can be used to differentiate between multiple entities
   retrieved from a single requested resource, as described in section
   13.6.

   If the Content-Location is a relative URI, the relative URI is
   interpreted relative to the Request-URI.

   The meaning of the Content-Location header in PUT or POST requests is
   undefined; servers are free to ignore it in those cases.



Fielding, et al.            Standards Track                   [Page 120]



; To UNSUBSCRIBE: Send "unsubscribe lynx-dev" to address@hidden