GETとPOST

HTTP POSTリクエストは、クライアント(ブラウザ)からサーバーへの追加データをメッセージ本文で提供します。 対照的に、 GET要求には、URLに必要なすべてのデータが含まれます。 HTMLのフォームは、 method = "POST"またはmethod = "GET" (デフォルト)を指定することにより、いずれかのメソッドを使用できます。 素子。 指定された方法により、フォームデータをサーバーに送信する方法が決まります。 メソッドがGETの場合、すべてのフォームデータはURLにエンコードされ、クエリ文字列パラメーターとしてアクション URLに追加されます。 POSTを使用すると、HTTP要求のメッセージ本文内にフォームデータが表示されます。

比較表

GET対POST比較チャート
取得する 役職
歴史パラメーターはURLの一部であるため、ブラウザーの履歴に残りますパラメータはブラウザの履歴に保存されません。
ブックマーク済みブックマークすることができます。ブックマークできません。
戻るボタン/再送信動作GETリクエストは再実行されますが、HTMLがブラウザのキャッシュに保存されている場合、サーバーに再送信されない場合があります。ブラウザは通常、データを再送信する必要があることをユーザーに警告します。
エンコードタイプ(enctype属性)application / x-www-form-urlencodedmultipart / form-dataまたはapplication / x-www-form-urlencodedバイナリデータにマルチパートエンコーディングを使用します。
パラメーター送信できますが、パラメータデータはリクエストライン(URL)に入れることができるものに制限されています。 2K未満のパラメーターを使用するのが最も安全で、一部のサーバーは最大64Kを処理しますファイルのアップロードを含むパラメーターをサーバーに送信できます。
ハッキングスクリプトキディのハッキングが簡単にハッキングがより難しい
フォームのデータ型の制限はい、ASCII文字のみ使用できます。制限なし。 バイナリデータも許可されています。
セキュリティ送信されるデータはURLの一部であるため、GETはPOSTと比較して安全性が低くなります。 そのため、ブラウザの履歴とサーバーログにプレーンテキストで保存されます。パラメータはブラウザの履歴やWebサーバーのログに保存されないため、POSTはGETよりも少し安全です。
フォームデータの長さの制限はい。フォームデータはURLにあり、URLの長さは制限されています。 安全なURLの長さの制限は多くの場合2048文字ですが、ブラウザとWebサーバーによって異なります。制限なし
使いやすさパスワードやその他の機密情報を送信するときは、GETメソッドを使用しないでください。パスワードまたはその他の機密情報を送信するときに使用されるPOSTメソッド。
可視性GETメソッドはすべてのユーザーに表示され(ブラウザーのアドレスバーに表示されます)、送信する情報の量に制限があります。POSTメソッド変数はURLに表示されません。
キャッシュ済みキャッシュ可能キャッシュされていません

フォーム送信の違い

METHOD = "GET"METHOD = "POST"の根本的な違いは、HTTP仕様で定義されているように異なるHTTP要求に対応することです。 両方のメソッドの送信プロセスは同じ方法で開始されます。フォームデータセットはブラウザによって構築され、 enctype属性で指定された方法でエンコードされます。 METHOD = "POSTの場合enctype属性はmultipart / form-dataまたはapplication / x-www-form-urlencodedにできますが、 METHOD =" GET "の場合はapplication / x-www-form-urlencodedのみが許可されます。次に、セットがサーバーに送信されます。

METHOD = "GET"を使用したフォーム送信の場合、ブラウザーはaction属性の値を取得し、 それに、フォームデータセット(application / x-www-form-urlencodedコンテンツタイプを使用してエンコードされた)を追加します。 ブラウザは、このURLをリンクをたどる(またはユーザーが直接URLを入力したかのように)処理します。 ブラウザはURLを部分に分割し、ホストを認識してから、そのホストにGETリクエストを送信し、残りのURLを引数として使用します。 サーバーはそこから取得します。 このプロセスは、フォームデータがASCIIコードに制限されることを意味することに注意してください。 ASCII形式のURLを介して他の文字を渡すときは、他の種類の文字をエンコードおよびデコードするために特別な注意を払う必要があります。

METHOD = "POST"を使用してフォームを送信すると、 アクション属性の値とenctype属性で指定されたコンテンツタイプに従って作成されたメッセージを使用して、POST要求が送信されます。

長所と短所

GETを使用すると、フォームデータはURLの一部として送信されるため、

  • フォームデータはASCIIコードに制限されています。 ASCII形式のURLを介して他の文字を渡すときは、他の種類の文字をエンコードおよびデコードするために特別な注意を払う必要があります。 一方、バイナリデータ、画像、その他のファイルは、すべてMETHOD = "POST"を使用して送信できます
  • 入力されたすべてのフォームデータは、URLに表示されます。 さらに、ユーザーのブラウザのWeb閲覧履歴/ログにも保存されます。 これらの問題により、 GETの安全性が低下します。
  • ただし、URLの一部として送信されるフォームデータの利点の1つは、URLをブックマークして直接使用し、フォーム入力プロセスを完全にバイパスできることです。
  • URLの長さには制限があるため、送信できるフォームデータの量には制限があります。
  • スクリプトキディは、システム内の脆弱性をより簡単に公開してハッキングすることができます。 たとえば、Citibankは、URL文字列のアカウント番号を変更することでハッキングされました。[1] もちろん、経験豊富なハッカーやWeb開発者は、POSTが使用されている場合でもこのような脆弱性を公開できます。 それはほんの少し難しいです。 一般に、サーバーは、クライアントから送信されたデータを疑い、安全でない直接オブジェクト参照から保護する必要があります。

サーバー側の処理の違い

原則として、送信されたフォームデータの処理は、 METHOD = "GET"またはMETHOD = "POST"で送信されるかどうかによって異なります。 データはさまざまな方法でエンコードされるため、さまざまなデコードメカニズムが必要です。 したがって、一般的に、METHODを変更すると、送信を処理するスクリプトの変更が必要になる場合があります。 たとえば、CGIインターフェイスを使用する場合、 GETが使用されると、スクリプトは環境変数(QUERYSTRING)のデータを受け取ります。 ただし、 POSTを使用する場合、フォームデータは標準入力ストリーム( stdin )で渡され、読み取られるバイト数はContent-lengthヘッダーによって指定されます。

推奨される使用法

「べき等」フォーム-「世界の状態を大幅に変更しない」フォームを送信する場合は、GETをお勧めします。 つまり、データベースクエリのみを含むフォーム。 別の観点では、複数のべき等クエリが単一のクエリと同じ効果を持つということです。 データベースの更新または電子メールのトリガーなどの他のアクションが関係する場合は、POSTの使用をお勧めします。

Dropbox開発者ブログから:

ブラウザは特定のHTMLフォームが何をするのかを正確に知りませんが、HTTP GETを介してフォームが送信された場合、ブラウザはネットワークエラーがある場合に送信を自動的に再試行しても安全であると認識します。 HTTP POSTを使用するフォームの場合、再試行しても安全ではない可能性があるため、ブラウザは最初にユーザーに確認を求めます。

多くの場合、「GET」リクエストはキャッシュ可能ですが、「POST」リクエストはほとんどキャッシュできません。 クエリシステムでは、特にクエリ文字列が単純な場合、キャッシュが最も頻繁なクエリを処理する可能性があるため、これは効率に大きな影響を与える可能性があります。

特定のケースでは、べき等のクエリに対してもPOSTの使用が推奨されます。

  • フォームデータに非ASCII文字 (アクセント付き文字など) が含まれる場合、 METHOD = "GET"は原則として適用できませんが、実際には機能する場合があります(主にISO Latin 1文字の場合)。
  • フォームデータセットが大きい場合 (数百文字など)、 METHOD = "GET"は、その長いURLを処理できない実装で実際的な問題を引き起こす可能性があります。
  • 特にURLに表示されないことで「非表示」フィールド(INPUT TYPE = "HIDDEN")を非表示にするために、フォームの動作をユーザーに見えにくくするために、 METHOD = "GET"を避けることをお勧めします。 ただし、 METHOD = "POST"で非表示フィールドを使用する場合でも、HTMLソースコードには表示されます。

HTTPSはどうですか?

2015年5月15日更新:特にHTTPS(HTTP over TLS / SSL)を使用する場合、POSTはGETよりも多くのセキュリティを提供しますか?

これは興味深い質問です。 WebページにGETリクエストを送信するとします。

 GET //www.example.com/login.php?user=mickey&passwd=mini 

インターネット接続が監視されていると仮定すると、このリクエストに関するどのような情報がスヌーパーに利用可能になりますか? 代わりにPOSTが使用され、ユーザーとpasswdデータがPOST変数に含まれている場合、HTTPS接続の場合はより安全ですか?

答えはいいえだ。 このようなGETリクエストを行うと、Webトラフィックを監視している攻撃者には次の情報のみが知られます。

  1. HTTPS接続を確立したという事実
  2. ホスト名-www.example.com
  3. リクエストの全長
  4. 応答の長さ

URLのパス部分(つまり、要求された実際のページ、およびクエリ文字列パラメーター)は、「有線」、つまり送信先サーバーへの転送中に保護(暗号化)されます。 状況は、POST要求の場合とまったく同じです。

もちろん、WebサーバーはアクセスログにプレーンテキストでURL全体を記録する傾向があります。 そのため、GETを介して機密情報を送信することはお勧めできません。 これは、HTTPまたはHTTPSが使用されているかどうかに関係なく適用されます。

関連記事