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
- [XHR][XHR2] HTTP redirects / XHR Version detection David Bruant
-