On Tue, 05 Feb 2008 00:30:03 +0100, Jonas Sicking <[EMAIL PROTECTED]> wrote:
I'm honestly not sure what the right thing to do here is. My gut feeling
is that the POST should go to the original URI and then any redirects
would need to follow the exact same path as the original OPTIONS
redirects.
That would incur way too much traffic and would also require a lot more
checking and more complicated algorithms. Since the current algorithm
checks at the end if a non-GET method is allowed for the referer root URI
it seems perfectly acceptable to me. It also gives you a very cheap way of
moving an API around.
This way the only difference between the cross-site POST and a same-site
POST will be the initial OPTIONS requests.
Actually, no. For each redirect you would need to perform an access check
in this case to ensure that a POST is actually allowed in the first place.
That seems like a bad idea to me since it makes cross-site requests
behave very different from same-site requests, rather than just
differing in authorization.
I don't see what the issue is. They already behave very differently as
they require a preflight OPTIONS request. Comments like these do worry
me a bit about the state of your implementation though. :-(
I decided not to implement redirects for non-GET methods at all in the
initial implementation. It might be the state we will ship in since I
think redirects is an edge case and the lack of support for redirect
won't hinder adoption of the rest of the spec.
I suppose you could claim it's a subset. I'd rather have fully compliant
implementations though, but I guess that will take some iterations anyway.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
