Advogato: Designing server-side applications in PHP. The main reason I'm blogging this is because of dan's comments that GET after POST isn't actually supposed to work, which is news to me:
If the 302 status code is received in response to a request other
than GET or HEAD, the user agent MUST NOT automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after receiving
a 302 status code, some existing HTTP/1.0 user agents will
erroneously change it into a GET request.
Dan's comments:
By the time they got to RFC 2616, they apparently realised that "some existing HTTP/1.0" user agents includes basically every useful browser out there, so they changed the wording to "most existing user agent[s]" and introduced new responses 303 (allow redirect from POST, always using GET) and 307 (don't redirect from POST, just like they originally intended 302 to have done). So you probably should be using a 303 instead of a 302 for this purpose. If your users know what it is. How do you test that? I've no idea: it seems unlikely that simply checking the HTTP request version for 1.1ness is going to be particularly accurate. Frankly I'd be a lot happier if they'd just repurposed 302 instead of creating 303, but we have to hope there was some good reason for not following existing practice there.
I have to do some experimenting, but for now, here's the relevant section in the HTTP RFC.
Tuesday, June 11, 2002
Permalink
"When automatically redirecting a POST request after receiving a 302 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request."
Heh... I had this exact problem when I was writing up my XML-RPC code and I had accidentally left the trailing slash off of the domain name... it kept converting my request to GET and messing everything up, I didn't notice until I broke down and installed Ethereal and nabbed the packets for myself.