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

Re: [XHR] Redirects

From: Darin Fisher <darin@chromium.org>
Date: Thu, 2 Sep 2010 11:09:53 -0700
Message-ID: <AANLkTinR7cL4UzbgZQ6DqUJBGVep3UUrV_b+QjdSPzCE@mail.gmail.com>
To: Anne van Kesteren <annevk@opera.com>
Cc: WebApps WG <public-webapps@w3.org>
On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren <annevk@opera.com> wrote:

> 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.

One more question:  suppose the author requests not to follow redirects.
 Should the .responseText property provide the response body sent with the
redirect?  Is there a use case for exposing the response body of a redirect

(I ask because in Chromium, the cache does not store response bodies for
cached redirects.  IIRC, Mozilla's cache is similar.)


>  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 Thursday, 2 September 2010 18:12:02 UTC

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