- 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>
On Wed, 01 Sep 2010 10:03:49 +0200, Darin Fisher <darin@chromium.org> wrote: > 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 http://annevankesteren.nl/
Received on Wednesday, 1 September 2010 08:17:01 UTC