ChrisB: Mit Umleitungen sparsam umgehen

Beitrag lesen

Hi,

Um das Zurückgehen und erneute Senden von POST-Daten zu verhindern, bedient man sich gern eines Tricks. Das per POST aufgerufenen Script verarbeitet die Daten und antwortet mit einem Location-Header. Der Browser ruft daraufhin das angegebene Ziel per GET auf. Ein Zurückgehen führt auf die Seite vor dem POST-Aufruf. Dass dieser Trick (soweit ich weiß) immer funktioniert, zeigt, dass ein Location-Header einen GET-Request zur Folge hat.

Nicht per se - es kommt auf den verwendeten 3xx-Statuscode an.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

"If the 301/302/307 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."

"303 See Other - The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource."

"Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request.  However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client."

Die POST-Daten werden dabei verworfen.

In den in der Praxis existierenden Implementierungen in den gaengigen Clients trifft das wohl weitgehend zu.
Fazit ist also, "Redirect mit POST-Daten" ist derart nicht "funktionierend" zu erreichen.

MfG ChrisB

--
"The Internet: Technological marvel of marvels - but if you don't know *what* you're lookin' for on the Internet, it is nothing but a time-sucking vortex from hell."