Re: redirect model for non-GET requests

Anne van Kesteren wrote:
> 
> 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.

I don't see why that would incur much more traffic than for a same-site 
POST that is redirected. Note that the OPTIONS requests can be cashed.

While it is a cheaper way to move an API around, a site will still have 
to deal with POSTs going to the original URI still since that is what 
will happen for same-site requests.

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

Right, note that I said "initial OPTIONS request_s_", i.e. you'll get 
one extra request for each redirect. But that should probably be the 
only difference.

Honestly, I don't feel very strongly either way. It would be good to get 
input from someone that knows HTTP better than me.

/ Jonas

Received on Tuesday, 5 February 2008 03:42:22 UTC