- From: David Bruant <dbruant@ucsd.edu>
- Date: Sat, 23 Jan 2010 14:05:50 -0800
- To: public-webapps@w3.org
Hi, My comments and questions are based on the editor's drafts (http://dev.w3.org/2006/webapi/XMLHttpRequest/ and http://dev.w3.org/2006/webapi/XMLHttpRequest-2). Between the two versions of the same-origin request event rules (#same-origin-request-event-rules), for the "If the response is an HTTP redirect" rule, the word "transparently" has disappeared. I understood the word "transparently" as "don't consider any other step of the algorithm" (like switching to the HEADERS_RECEIVED state, because if a redirect has been detected, it means that the headers has been received at least the location header). The absence of this word in XHR2 suggests that the state should be switched to HEADERS_RECEIVED even if it is a redirect. So, more generally, my question is : for HTTP redirects, should the implementations of XHR and XHR2 switch the state to HEADERS_RECIEVED ? I don't know how it is currently implemented by the current browsers, but I would be in favor of switching the state (and thus dispatch an event) so that authors could write tools allowing them to have an idea of the number of redirects generated by some URL and then do an analysis of their websites (for instance all the links within a HTML page) "from the client side". My next question should find its answer thanks to the previous one, but juste to be sure : Is it possible that the state be to DONE and the status be a redirect (300 <= status < 400) ? If the behavior has changed between XHR and XHR2, how authors can know what version is implemented by user agents ? In other words, is there a way defined by the spec to make the difference between a XHR "conforming user agent" and a XHR2 "conforming user agent" since the interface has the same name (XMLHttpRequest) ? Thanks, David
Received on Monday, 25 January 2010 02:31:52 UTC