On Thu, 05 Mar 2009 10:18:39 +0100, Jonas Sicking <jo...@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/
