Re: [cors] Redirects and preflights

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?

Yes.


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


> 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
http://annevankesteren.nl/

Received on Monday, 16 March 2009 16:53:57 UTC