- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 04 Feb 2008 19:40:20 -0800
- To: Anne van Kesteren <annevk@opera.com>
- CC: "WAF WG (public)" <public-appformats@w3.org>
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