Re: redirect model for non-GET requests

On Tue, 05 Feb 2008 00:30:03 +0100, Jonas Sicking <jonas@sicking.cc> 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/>

Received on Tuesday, 5 February 2008 00:45:02 UTC