Re: [XHR] Redirects

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
page?

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

-Darin


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