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

+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
mnot@yahoo-inc.com

Received on Saturday, 9 September 2006 04:36:39 UTC