- From: Darin Fisher <darin@chromium.org>
- Date: Wed, 1 Sep 2010 14:59:17 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: WebApps WG <public-webapps@w3.org>
- Message-ID: <AANLkTim+f6nfhvzvciBZ-YnmMgajjt-Yhj_t8qF5nsmy@mail.gmail.com>
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. > > The problems I've raised here are real problems that I've observed while building HTTP implementations for Mozilla and Chromium. It is easy for good coders to make these kinds of mistakes. -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/ >
Received on Wednesday, 1 September 2010 21:59:47 UTC