What the hell with 301 Moved Permanently HTTP header!? I'll take an
exemple to explain my ugly problem, take, a (very ugly cause it's PHP)
index.php, it could be retrieved by using:
Got the page, 200 OKor
Got the page, 200 OKor
Got a 301 Moved Permanently Location:...
Just like expected ... but...
As you can see, on the captured HTTP headers below, when you POST data on a 301 target, you'll be redirected, but unfortunately you'll lost your POST data, even worse, your request can be reforged as a GET request! Let me show you an example: Request:
POST /directory HTTP/1.1 Host: example.com [user agent, referer, cache control, origin, content type, accept, ...] Content-Length: 7 foo=bar
HTTP/1.0 301 Moved Permanently Location: http://example.com/directory/ ...
GET /directory/ HTTP/1.1 Host: example.com
Why my data isn't kept in the reforged one!? So let's read The
10.3.2 301 Moved Permanently [...] The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 301 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 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
Ahh, ok, so, for request other than
HEAD, the user agent
MUST NOT automatically redirect to the request? Ugh, it's not the
case in IE 6, 7, 8, Firefox, nor Chrome. And, about the security,
while the server recieves the data, it can do everything, for example
send it to another server directly. Then I'm wondering, why asking to
the user if he allows his data to be transfered? Then, the RFC says
an interesting thing...
Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.
But, not only HTTP/1.0 user agents, but HTTP/1.1 user agents like
browsers and frameworks (as, I encountred the problem firstly in the
.NET Framework 3.5, in
Reforging as a GET is clearly not a good idea, but on the other hand,
POST requests are not idempotent, we're still happy they're not
executed twice: Imagine the POST is "Pay for that shiny new laptop",
the payment is executed, but later in the request execution, a 301 to
another server is generated, if your client re-POST the same request
on the other server, your payment may be executed
twice... outch. Respecting idempotency looks clearly more important
than generating dumb
GET, harmless, requests.
Hope it helps...