Le 30/01/2010 04:41, Anne van Kesteren a écrit :
On Sat, 23 Jan 2010 23:05:50 +0100, David Bruant <[email protected]>
wrote:
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".
The idea is actually that a redirect does not involve a "state"
transition. I have suggested on this mailing list a way to control
whether redirects are followed but due to lack of response I have not
done anything with it so far.
Ok.
The use case that could require to not follow silently or to follow
silently but still leaving so kind of trace of redirects is a project I
am currently working on : http://wiki.github.com/DavidBruant/linkChecker/
This is still very experimental (and a mess !) and not really ready to
be deployed on actual websites. But the idea is to execute some JS on
the client side and create a "report" of all resource links that can be
found. Because it is run on the client side, if some content brought
asynchronously contains links, these can be tested too (what is not true
about this static checker : http://validator.w3.org/checklink).
I think that the "clients" of my library could be interested in knowing
if some links involve none or one or a lot of redirects. Redirects imply
back and forth communication between client and server, as a
consequence, they can affect performance of applications.
For that reason, it could be interesting for me to provide the number of
redirects and the different intermediate locations in the report. It
would be a good way to provide a full analysis of the HTTP traffic.
Would it be clearer if after "Once all HTTP headers have been received
and the asynchronous flag is true" I added "(and this is not an HTTP
redirect)"?
I think that because receiving HTTP headers are chronologically the
first thing that happens, it could be the first written :
"Once all HTTP headers have been received and the asynchronous flag is true"
"if it is an HTTP redirect then blabla"
"if it is not, blabla".
Now I know that the semantic of the HEADERS_RECEIVED state is not
"headers received", but "headers of the expected/final resource
received", I think it would deserve some sort of note at this
(http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#headers-received-state)
moment to explain that it is not only a matter of recieving "some/any"
headers, but there is also the notion of final/expected resource.
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 there is no Location header this is possible. (Have not tested
whether this is correctly implemented.)
Ok, thank you.
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) ?
No, because in general user agents do not implement everything from
one or the other. E.g. a couple of user agents implemented features
from XHR2 but are not at all conforming to XHR1 requirements that did
not change in XHR2. Implementations evolve organically, not in
concrete steps.
So, why having two specifications in a working draft state ? Wouldn't it
be easier for maintenability of the specs to have only the XHR2 spec and
notes about legacy behaviors (and attributes/methods) ?
Will XHR1 reach the recommandation state one day ? Will it make sense ?
Thank you for the answer.
David
