+1
RFC2616 on the Location header:
For 3xx responses, the location SHOULD indicate the
server's preferred URI for automatic redirection to the resource.
...which implies that automatic redirection is sanctioned (except
where prohibited for particular status codes).
I like the idea of a property specified by XHR; while DOM 3 does it
as well, that isn't widely supported AFAIK. Maybe specifically refer
to the DOM 3 properties and encourage XHR developers to implement them?
Another approach would be checking the Content-Location header, but
that requires work on the server side.
On 2006/09/08, at 4:20 PM, L. David Baron wrote:
On Friday 2006-09-08 18:17 -0400, Tim Berners-Lee wrote:
However, the XMLHTTPRequest document [2] says:
"If the response is an HTTP redirect (status code 301, 302, 303 or
307), then it must be transparently followed (unless it violates
security, infinite loop precautions or the scheme isn't supported)."
This is a bug. The 303 response should be returned to the software,
so that it can interrogate the Location header, and pick up
information from the associated document should it wish to. An
alternative would be for the history of what happened to provided in
linked status blocks after a single call.
This proposal makes one use case much more complex in order to make
another one possible. I don't think this complexity is necessary. If
there were a way of determining whether one or more 303 redirects
occurred on the way to the retrieval of the final response, would that
be sufficient?
It is also, by the way, very useful to be able to get at the 301 and
302 status details, particularly when many URIs redirect to the same
thing, which might already have been fetched.
This performance optimization should be expected to be made by the
HTTP
caching implementation underlying the XMLHttpRequest
implementation. In
most cases, this should be sufficient. (When it's not, the user
may in
many cases want to check the response against a previous retrieval of
the same resource before assuming that the contents are the same,
given
the complex caching rules for HTTP.)
Transparent redirection with implementation caching seems far less
likely to cause the consumer of XMLHttpRequest to accidentally ignore
the rules on caching defined for the HTTP protocol.
Furthermore, Web authors and Web server administrators expect
redirects
to "work", i.e., be followed transparently. An XMLHttpRequest
implementation that did not follow redirects would be considered
unambiguously broken. Given the rationale for the creation of 303 and
307 redirects given in the HTTP specification, I think authors
would be
quite surprised if 303 redirects were treated differently.
There is also a problem with relative URIs in the destination
document. They should be parsed relative to the redirected URI (for a
302 Moved at , not the original URI, but the software knows nothing
about the redirection. This must apply also to other redirections.
It seems like the ideal solution for this would be a
"responseLocation"
or "responseURI" property that gives the URI of the document contained
in responseText/responseXML. I think a significant number of
consumers
of XMLHttpRequest could find such a property useful.
While I was looking at the spec [2], I noticed that a number of things
in it are ambiguous when redirects are involved. In particular, I
noticed that the status and statusText properties are not clearly
defined (which status?), and it is not clear whether
getAllResponseHeaders includes headers from all redirection steps
(although it seems clear for getResponseHeader).
-David
[2] http://www.w3.org/TR/XMLHttpRequest/#xmlhttprequest
--
L. David Baron <URL: http://
dbaron.org/ >
Technical Lead, Layout & CSS, Mozilla Corporation
--
Mark Nottingham
[EMAIL PROTECTED]
