[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: lynx-dev base href -- how generated by Lynx?
From: |
Leonid Pauzner |
Subject: |
Re: lynx-dev base href -- how generated by Lynx? |
Date: |
Sun, 2 Mar 2003 22:41:42 +0300 (MSK) |
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