W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2010

Re: [XHR] Redirects

From: Anne van Kesteren <annevk@opera.com>
Date: Wed, 01 Sep 2010 10:16:19 +0200
To: "Darin Fisher" <darin@chromium.org>
Cc: "WebApps WG" <public-webapps@w3.org>
Message-ID: <op.vicg9dqe64w2qv@anne-van-kesterens-macbook-pro.local>
On Wed, 01 Sep 2010 10:03:49 +0200, Darin Fisher <darin@chromium.org>  
> On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren  
> <annevk@opera.com>wrote:
>> This does not work for synchronous requests in a worker.
> Hmm, good point.  An alternative design might be a flag that causes  
> .send() to complete once a redirect response is received, but then also  
> provide a
> method on the XHR object to tell it to now follow the redirect.  This  
> model would work for both synchronous as well as asynchronous.

That seems like the current design, except we currently do not have that  
additional method. I would like to keep it out until it is more clear this  
is a real problem. It would add quite a bit of complexity whereas just  
having this is fairly straightforward.

> I thought of another reason to want the original XHR object to be
> responsible for following the redirect:  the value of a Location header  
> may be a relative URL.  It would be nice if application authors did not  
> have to take care of resolving that manually.  (In the case of a  
> cross-origin
> request, the relative URL should be resolved relative to the URL that was
> redirected instead of against the Document.)  This seems like something  
> that could be easy to mess up.

Yeah, I thought of that. There's location.resolveURL(), but it does not  
take a base URL at the moment. We could add that. Though note that  
relative URLs are forbidden in theory.

Anne van Kesteren
Received on Wednesday, 1 September 2010 08:17:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:11 UTC