it-swarm.com.de

Warum hat HTTP keine POST Weiterleitung?

HTTP-Weiterleitungen erfolgen über die HTTP-Codes 301 und 302 (möglicherweise auch andere Codes) und ein Header-Feld namens "Location", das die Adresse des neuen Zielorts enthält. Browser senden jedoch immer eine "GET" -Anforderung an diese URL.

Oft müssen Sie Ihren Benutzer jedoch über POST (z. B. Bankzahlungen)) auf eine andere Domain umleiten. Dies ist ein häufiges Szenario und wirklich eine Anforderung. Weiß jemand, warum eine solche allgemeine Anforderung vorliegt? wurde in der HTTP-Spezifikation vernachlässigt? Die Problemumgehung besteht darin, ein Formular (mit Parametern in ausgeblendeten Feldern) zu senden, dessen Aktion auf den Zielspeicherort (den Wert des Felds Standort Header) festgelegt ist, und setTimeout, um das Formular an den Zielort zu senden.

181
Saeed Neamati

In HTTP 1.1 gibt es tatsächlich einen Statuscode ( 7 ), der angibt, dass die Anforderung mit derselben Methode und denselben Postdaten wiederholt werden soll.

Wie andere gesagt haben, gibt es hier ein Missbrauchspotential, weshalb viele Frameworks in ihren Abstraktionen an 301 und 302 festhalten. Mit richtiges Verständnis und verantwortungsbewusster Umgang sollten Sie jedoch in der Lage sein, das zu erreichen, wonach Sie suchen.

Beachten Sie, dass gemäß W3.org spec , wenn das METHOD nicht HEAD oder GET ist, Benutzeragenten das auffordern sollten Benutzer vor dem erneuten Ausführen der Anforderung am neuen Speicherort. Sie sollten auch einen Hinweis und einen Fallback-Mechanismus bereitstellen für den Benutzer, falls alte Benutzeragenten nicht sicher sind, was sie mit einem 307 tun sollen.

Mit diesem Formular:

<form action="Test307.aspx" method="post">
    <input type="hidden" name="test" value="the test" />
    <input type="submit" value="test" />    
</form>

Und wenn Test307.aspx einfach 307 mit dem Speicherort zurückgibt: http://google.com , Chrome 13 und Fiddler bestätigen, dass "test = the test" tatsächlich ist Natürlich ist die weitere Antwort eine 405, da Google den POST nicht zulässt, aber die Mechanik zeigt.

Weitere Informationen finden Sie unter Liste der HTTP-Statuscodes und W3.org-Spezifikation .

307 Temporäre Umleitung (seit HTTP/1.1) In diesem Fall sollte die Anforderung mit einem anderen URI wiederholt werden, zukünftige Anforderungen können jedoch weiterhin den ursprünglichen URI verwenden. 2 Im Gegensatz zu 303 sollte die Anforderungsmethode dies nicht tun geändert werden, wenn die ursprüngliche Anfrage erneut ausgestellt wird. Zum Beispiel muss eine POST - Anfrage mit einer anderen POST - Anfrage wiederholt werden.

187
David Ruttka

Ich habe eine gute Erklärung dafür gefunden Seite hier .

Die einfachsten Situationen im WWW sind "idempotente" Transaktionen, d. H. Solche, die wiederholt werden können, ohne Schaden zu verursachen. Hierbei handelt es sich in der Regel um "GET" -Transaktionen, entweder weil einfache URL-Referenzen abgerufen werden (z. B. href = oder src = Attribute in HTML) oder weil es sich um Formularübermittlungen mit der GET-Methode handelt. Das Umleiten einer Transaktion dieser Art ist unkompliziert und es werden keine Fragen gestellt: Der Client erhält die Umleitungsantwort, einschließlich eines Location: -Headers, der die neue URL angibt, und der Client reagiert darauf, indem er die Transaktion erneut an die neue URL ausgibt. Es gibt einen Unterschied zwischen den verschiedenen 30x-Statuscodes, die diesen Umleitungen zugeordnet sind, in ihrer impliziten Cachefähigkeit, aber ansonsten sind sie in Reaktion auf GET-Anforderungen grundsätzlich ähnlich (301 und 302).

POST-Transaktionen sind unterschiedlich, da sie im Prinzip als nicht idempotent definiert sind (z. B. Bestellung einer Pizza, Stimmabgabe oder was auch immer) und nicht willkürlich wiederholt werden dürfen.

Die HTTP-Protokollspezifikationen berücksichtigen diese Unterscheidung: Die GET-Methode ist als inhärent idempotent definiert, während die Methode POST) als zumindest potenziell nicht idempotent definiert ist. Die Spezifikationen erfordern eine Reihe von Vorsichtsmaßnahmen, die von Client-Agenten (z. B. Browsern) getroffen werden müssen, um Benutzer vor dem versehentlichen (erneuten) Senden einer POST - Transaktion, die sie durchführen, zu schützen hatte nicht beabsichtigt oder ein POST in einen Kontext eingereicht, den sie nicht gewollt hätten.

Ich bin zwar kein Fan davon, Benutzer technisch einzuschränken, um zu verhindern, dass sie unerwünschtes Chaos verursachen oder ihren Anwendungen unerwünschten Schaden zufügen, aber ich kann den Punkt verstehen und es ist sinnvoll.

49
Falcon

GET (und einige andere Methoden) sind in der http-Spezifikation ( RFC 2616 ) als 'SAFE' definiert:

9.1.1 Sichere Methoden

Implementierer sollten sich bewusst sein, dass die Software den Benutzer bei ihren Interaktionen über das Internet repräsentiert, und sollten darauf achten, dass der Benutzer über mögliche Maßnahmen informiert wird, die für sich selbst oder andere von unerwarteter Bedeutung sein können.

Insbesondere wurde die Konvention festgelegt, dass die Methoden GET und HEAD NICHT die Bedeutung haben sollten, eine andere Aktion als das Abrufen auszuführen. Diese Methoden sollten als "sicher" betrachtet werden. Dies ermöglicht Benutzeragenten andere Methoden wie POST, PUT und DELETE auf besondere Weise darzustellen, damit der Benutzer darauf aufmerksam gemacht wird, dass eine möglicherweise unsichere Aktion angefordert wird.

Natürlich kann nicht sichergestellt werden, dass der Server durch die Ausführung einer GET-Anforderung keine Nebenwirkungen erzeugt. In der Tat betrachten einige dynamische Ressourcen dies als eine Funktion. Der wichtige Unterschied besteht darin, dass der Benutzer die Nebenwirkungen nicht angefordert hat und daher nicht für sie zur Rechenschaft gezogen werden kann.

Dies bedeutet, dass eine GET-Anforderung für den Benutzer niemals ernsthafte Konsequenzen haben sollte, außer dass er etwas sieht, das er möglicherweise nicht sehen möchte. Eine POST -Anforderung kann jedoch eine Ressource ändern, die für ihn oder für ihn wichtig ist andere Leute.

Obwohl sich dies mit JavaScript geändert hat, gab es traditionell verschiedene Benutzeroberflächen - Benutzer konnten GET-Anforderungen durch Klicken auf Links auslösen, mussten jedoch ein Formular ausfüllen, um eine POST -Anforderung auszulösen. Ich denke, die Designer von HTTP waren daran interessiert, die Unterscheidung zwischen sicheren und nicht sicheren Methoden beizubehalten.

Ich denke auch nicht, dass es jemals notwendig sein sollte, zu einem POST umzuleiten. Jede Aktion, die ausgeführt werden muss, kann vermutlich durch Aufrufen einer Funktion im serverseitigen Code oder auf einem anderen Server ausgeführt werden, anstatt eine Umleitung mit einer URL für den Browser an POST to, der Server könnte eine Anfrage an diesen Server selbst stellen und sich wie ein Proxy für den Benutzer verhalten.

2
bdsl