27th
XHR and Redirects
The XHMHttpRequest working draft includes this gem about handling redirects:
If the redirect does not violate security (it is same origin for instance), infinite loop precautions, and the scheme is supported, transparently follow the redirect while observing the same-origin request event rules.
Modern browsers appear to handle this correctly. Cheers to them for following the spec. However, this is quite the pain when you want granular control, from the client side, of whether to follow the redirect. If you want that control, you’re pretty much SOL without changing the server. The redirect gets followed and the response available is the response to the second (or subsequent if there are more than one redirects) request.
From the server side you could detect that the request is an XHR and send a different or special response code which the client could then interpret as needed, but that places complexity in the server that should be in the client.
In many cases, following the redirect may not matter. The client side can ignore the content and carry on as it needs but there’s something sort of fundamentally anti-web in this act of transparently and magically doing more than one request from a client-side programming environment. The fundamental granular piece of the web is the one request/response interaction.
