On Sun, 31 Jan 2010 00:45:17 +0100, David Bruant <[email protected]> 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/
