Re: XMLHTTPRequest: HTTP 303 response must be visible to caller

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