I saw some examples for those redirects and they seem to send even an invalid Location header:
Location: /?somekey It's illegal for the Location header to contain a relative URL: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30 This causes APIs like twitter4j on Google App Engine to fail. Making this a absolute URL would work... or would that somehow break the security measuers taken? Maybe the Twitter dev team can consider to make the Location URLs absolute, a lot of us would then at least be able to do some stuff with Twitter while these attacks take place. Cheers Sven On Aug 7, 12:44 pm, Chad Etzel <[email protected]> wrote: > Inline about 302's. I'm trying to get info on your other questions: > > On Fri, Aug 7, 2009 at 3:27 PM, Justin Hart<[email protected]> wrote: > > Does this affect POST as well as GET? The issue here is the way > > clients handle 30x after POST. Most clients (now by convention) do > > not respect the RFC (http://www.w3.org/Protocols/rfc2616/rfc2616- > > sec10.html#sec10.3) and will send a GET after POST always. Some > > clients will respect the method, but not re-post any data. We need to > > be sure we are all expecting the right things. > > You are correct that lots of clients now redirect with a GET instead > of a POST, even curl does this, which is a bummer. > > The best thing to do in that case is to catch the response code > (without following the redirect automatically) and manually re-attempt > the POST with the new location. > > We know it's a pain, but that's one way around the POST->GET problem. > > -Chad
