On Wed, Sep 1, 2010 at 1:16 AM, Anne van Kesteren <ann...@opera.com> wrote:
> On Wed, 01 Sep 2010 10:03:49 +0200, Darin Fisher <da...@chromium.org> > wrote: > >> On Tue, Aug 31, 2010 at 11:26 PM, Anne van Kesteren <ann...@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/ >
