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 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 00:45:03 GMT