Re: [XHR] Redirects

On Tue, Aug 31, 2010 at 1:16 PM, Anne van Kesteren <annevk@opera.com> wrote:

> On Tue, 31 Aug 2010 19:04:08 +0200, Darin Fisher <darin@chromium.org>
> wrote:
>
>> So the idea is that you would have to manually create the redirect request
>> using a new XHR if you wanted to manually follow the redirect?
>>
>
> Yeah, or you could reset the existing object using open().
>
>
>
>  One risk with that is that it is easy to construct the redirect request
>> improperly.  There's the classic example of what happens when you issue a
>> POST request and it results in a redirect.  303 and 307 had to be invented
>> because some browsers implemented 302 incorrectly.
>>
>
> Yeah, though I think that the people that implement redirects manually have
> put some thought in the matter. Maybe that is naive, though on the other
> hand if people do it wrong it does not matter much either.
>
>
>
>  Maybe there should be a way to create a new XHR from the existing XHR that
>> is already configured to follow the redirect?  I'm not sure how to make this
>> less awkward...
>>
>
> If this is actually common and people start using this a lot and ask this
> question here that would be the point where we should start thinking about
> making this less awkward. For now libraries and developers with "lots of
> time" have all the hooks they need.
>
>
>
>

Hmm, that's a pretty good argument.

Another issue that concerns me is redirect loops.  The proposed API gives us
know way to know that the application is following a redirect chain, which
means that we have little way to know if the application is following an
endless redirect chain.  The classical example is a server that redirects
back to the same URL with a Set-Cookie header, expecting the next request to
have a corresponding Cookie header.  If the Cookie header is not added, then
the redirect is issued again.

Most browsers detect this after N iterations, and then give up.  Of course,
this situation only occurs if the user has disabled cookies in the User
Agent.  I worry that a case like this will almost never be tested by
application developers, and hence, users who like to disable some cookies
will be unable to use the internet.  (I realize that the internet is mostly
broken already if you disable cookies, but there are some variations of
cookie blocking that sort of work.)

A User Agent could try to implement a heuristic to catch certain flavors of
redirect chains, by observing the XHR requests made by an application.  But,
it seems like it would be fairly difficult to avoid false positives.

If instead, we had an API for auditing redirects (perhaps an "onredirect"
event), then we could let developers handle that event and call
preventDefault if they want to stop redirect processing.  Otherwise, the
redirect would be processed normally.  The result being that application
authors would be guided away from following redirects manually, and hence
they would avoid the problems I've described above.

-Darin