Re: [XHR][XHR2] HTTP redirects / XHR Version detection

Le 30/01/2010 04:41, Anne van Kesteren a écrit :
> On Sat, 23 Jan 2010 23:05:50 +0100, David Bruant <dbruant@ucsd.edu> 
> 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

Received on Saturday, 30 January 2010 23:45:49 UTC