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

On Sun, 31 Jan 2010 00:45:17 +0100, David Bruant <dbruant@ucsd.edu> wrote:
> Le 30/01/2010 04:41, Anne van Kesteren a écrit :
>> 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.

Yeah. Control over redirects would be cool to have to "lengthen" shortened  
URLs too. I think I will wait a bit with adding it until implementations  
of the features currently in the XHR2 draft are more stable though.  
Especially since last I asked nobody was jumping up and down for it. :-)


>> 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".

Well, theoretically you can detect a redirect before all HTTP headers of a  
response have been received. Regardless, I'll clarify the situation.


> 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.

Good point. I'm in the middle of other edits at the moment, but I will get  
to this after those.


>>> 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 ?

Since recently both specifications are created from the same source  
document so maintenance is no longer an issue for me. Some people see  
value in XHR1 and since the cost of maintaining it is now very low I have  
no problem pushing it forward. If it turns out that eventually we have two  
interoperable implementations of XHR2 we could decide to abandon further  
development of XHR1 I suppose, but there's no real need to decide any of  
that now.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Sunday, 31 January 2010 10:36:29 UTC