web-dev-qa-db-ja.com

HTTPにPOSTリダイレクトがないのはなぜですか？

HTTPリダイレクトは、HTTPコード301および302（おそらく他のコードも）と、新しい場所のアドレスを含む「ロケーション」と呼ばれるヘッダーフィールドを介して行われます。ただし、ブラウザは常に「GET」リクエストをそのURLに送信します。

ただし、多くの場合、POST（銀行支払いなど）を介してユーザーを別のドメインにリダイレクトする必要があります。これは一般的なシナリオであり、実際には要件です。そのような一般的な要件を知っている人はいますか？ HTTP仕様で無視されていますか？回避策は、アクションが設定されたフォーム（非表示フィールドにパラメーターがある）をターゲットの場所（Locationヘッダーフィールドの値）に送信し、setTimeoutフォームをターゲットの場所に送信します。

web-developmentweb-applicationshttp
181
Saeed Neamati

HTTP 1.1では、実際にはステータスコード（ 7 ）があり、同じメソッドを使用してリクエストを繰り返す必要があることを示します投稿データ。

他の人が言ったように、誤用の可能性がここにあるので、多くのフレームワークが抽象化で301と302に固執しているのかもしれません。ただし、を適切に理解し、責任ある使用法を使用することで、は、探していることを達成できるはずです。

W3.org仕様 によると、METHODがHEADまたはGETではない場合、ユーザーエージェントは新しい場所でリクエストを再実行する前に、ユーザーにプロンプ​​トを表示します。古いユーザーエージェントが307の処理方法がわからない場合に備えて、ユーザーにメモとフォールバックメカニズムを提供する必要もあります。

このフォームを使用する：

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

そして、Test307.aspxを使用すると、次の場所で307が返されます： http://google.com 、Chrome 13そしてFiddlerは、「test = the test」が本当にGoogleにはPOSTが許可されていないため、当然、これ以上の応答は405ですが、メカニズムを示しています。

詳細については、 HTTPステータスコードのリスト および W3.org仕様 を参照してください。

307一時的なリダイレクト（HTTP/1.1以降）この場合、リクエストは別のURIで繰り返される必要がありますが、今後のリクエストでは引き続き元のURIを使用できます。 2 303とは異なり、リクエストメソッドは元のリクエストを再発行するときに変更されます。たとえば、POSTリクエストは、別のPOSTリクエストを使用して繰り返す必要があります。

187
David Ruttka

私はこれについて良い説明を見つけました ここのページ 。

WWWの最も単純な状況は「べき等」トランザクションです。つまり、害を及ぼすことなく繰り返すことができます。これらは通常、「GET」トランザクションです。これは、単純なURL参照（HTMLのhref =またはsrc =属性など）を取得するため、またはGETメソッドを使用してフォームを送信するためです。この種のトランザクションのリダイレクトは単純で、質問もありません。クライアントは、新しいURLを指定するLocation：ヘッダーを含むリダイレクト応答を受信し、クライアントは新しいURLにトランザクションを再発行することによってそれに応答します。これらのリダイレクトに関連付けられているさまざまな30xステータスコードには、暗黙のキャッシュ可能性に違いがありますが、それ以外は基本的にGETリクエストへの応答は似ています（301と302）。

POSTトランザクションは、原則として非べき等（ピザの注文、投票など）であると定義されているため異なるものであり、任意に繰り返すことはできません。

HTTPプロトコルの仕様は、この違いを考慮に入れて設計されています。GETメソッドは本質的にべき等であるように定義されていますが、POSTメソッドは、少なくとも潜在的に非べき等であるように定義されています;仕様では、ユーザーを誤って（再）送信しないようにユーザーを保護するために、クライアントエージェント（ブラウザなど）がいくつかの予防策を講じることを求めていますPOST彼らが行うトランザクション意図していない、またはPOSTを彼らが望んでいないコンテキストに送信していませんでした。

私は、ユーザーに不要な騒乱を引き起こしたり、アプリケーションに望ましくない危害を加えたりすることを防ぐためにユーザーを技術的に制限するのが好きではありませんが、要点は理解でき、理にかなっています。

49
Falcon

GET（および他のいくつかのメソッド）は、http仕様（ RFC 2616 ）で「SAFE」として定義されています。

9.1.1安全な方法

実装者は、ソフトウェアがインターネット上でのやり取りにおいてユーザーを表すことを認識している必要があり、自分や他の人に予期しない重要性をもたらす可能性のあるアクションをユーザーが認識できるように注意する必要があります。

特に、GETおよびHEADメソッドは、取得以外のアクションを実行することの重要性を持たないでください。これらのメソッドは「安全」と見なされるべきです。これにより、ユーザーエージェントがPOST、PUT、DELETEなどの他のメソッドを特別な方法で表すため、ユーザーは安全でない可能性のあるアクションが要求されているという事実に気づくことができます。

当然、GETリクエストを実行した結果としてサーバーが副作用を生成しないようにすることはできません。実際、一部の動的リソースはその機能を考慮しています。ここでの重要な違いは、ユーザーが副作用を要求しなかったため、それらに対して責任を負うことができないことです。

つまり、GETリクエストは、ユーザーが見たくないものを見ることを超えて、ユーザーに深刻な結果をもたらすことは決してありませんが、POSTリクエストは、ユーザーにとって重要なリソースを変更したり、他の人。

これはJavaScriptで変更されましたが、従来はさまざまなユーザーインターフェイスがありました。ユーザーはリンクをクリックしてGETリクエストをトリガーできましたが、POSTリクエストをトリガーするにはフォームに入力する必要がありました。デザイナーはHTTPは安全な方法と安全でない方法の区別を維持することに熱心でした。

また、POSTにリダイレクトする必要はないと思います。実行する必要のあるアクションは、サーバー側のコード内の関数を呼び出すか、別のサーバーで実行する必要がある場合は、ブラウザーのURLを含むリダイレクトをPOST toの場合、サーバーはそのサーバー自体に要求を出し、ユーザーのプロキシのように機能します。

2
bdsl