W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: [cors] Redirects and preflights

From: Anne van Kesteren <annevk@opera.com>
Date: Mon, 16 Mar 2009 17:52:57 +0100
To: "Jonas Sicking" <jonas@sicking.cc>
Cc: "Webapps WG" <public-webapps@w3.org>
Message-ID: <op.uqv86j1f64w2qv@annevk-macbook.lan>
On Thu, 05 Mar 2009 10:18:39 +0100, Jonas Sicking <jonas@sicking.cc> wrote:
> [...] So this is quite a common pattern on the web today, and ideally  
> should
> be more common.

The pattern is typically implemented using 302, but yeah...

> For this setup it makes a lot of sense to not redirect a OPTIONS
> request, but to redirect a POST request to the same uri.

Which URI?

And what happens if that is a redirect as well?

>>> What should be done in the following scenario:
>>> 1. A page on site A initiates a DELETE request to a uri on site B
>>> 2. The UA makes a preflight OPTIONS request to the uri on site B
>>> 3. The site responds with a 303 to a different uri on site B.
>> Currently the specification treats all redirects the same. I guess we  
>> could special case 303.
> In the setup described above, even if the server redirects the
> add-item-to-cart OPTIONS response to the display-shopping-cart uri, it
> makes little sense to redirect the POST there. That would never have
> happened for a same-site POST request going to the add-item-to-cart
> uri.

It's not clear to me what you want to change here.

>>> Should perhaps
>>> a 303 redirect mean that the DELETE request should be made to the
>>> initial uri on site B, assuming that the preflight after redirects
>>> ended up returning a response with the appropriate headers?
>> No, that seems wrong.
> Why? A 303 just means that the response is located elsewhere, not that
> the action is performed by a different uri.

So you mean that we treat 303 specially for OPTIONS requests but not 301,  
302 and 307?

>>> I don't have strong opinions on this one. But a gut feeling is that
>>> only a 307 should cause the DELETE to go somewhere else as that is the
>>> only time when that would have happened if the DELETE would have been
>>> done directly to the first uri on site B.
>> 301 and 302 should do that too.
> Why? Note that 302 is basically treated as a 303 by most browsers
> today just because what the spec says is basically terrible UI asking
> the user to make a decision he/she does not have enough information to
> make.

I know. And it is somewhat unfortunate that the RFC 2616bis guys are not  
taking this into account. How is 307 different with respect to the  
terrible UI though?

>>> I think the fact that there is upload event listeners should be
>>> measured just on the initial request. So in the example above the
>>> redirect should be followed but no events would be fired on the upload
>>> object.
>> I think this is already clear in the specification.
> My understanding is that the answer is that it's only measured in the
> beginning. Is this correct?


> As described above, it is in fact the recommended way to allow the UA
> to fetch the response to the request multiple times without causing
> the action to happen every time. So there are several servers out
> there that behave this way already, and once we add support for
> redirects to XHR, it's most likely something that developers will want
> to do in XHR as well.

Maybe. I'm not sure if the cases that go for forms apply to XMLHttpRequest  
scenarios as well though I agree it would be nice to just follow HTTP here.

>>> * When making the OPTIONS preflight request, only change the
>>> destination uri of the actual request if the response is a 307.
>> Why not for 301 and 302?
> In my examples I've used 303 and 307 as they are the most unambigios
> redirections. 302 is generally treated as 303, though the spec allows
> it to be treated as a 307 after asking for user permission.

I think 307 requires permission as well.

> I'm unclear on how 301s are supposed to work, but at least in gecko they
> do seem to behave like a 303, though with some effect on following
> requests that I haven't yet dug in to (which is what sets them, as
> permanent redirects, apart from temporary redirects).

I think implementations agree here, though HTTP does not agree with the  

> In short, I think the spec currently misunderstands the HTTP protocol
> by treating all redirects as redirects of the request, whereas many of
> them are just redirects of the response.

Fair enough. Do you have specific suggestions for how we should handle  
them instead?

Anne van Kesteren
Received on Monday, 16 March 2009 16:53:57 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:14 UTC