post: 処理対象のデータを指定されたリソースに送信します。データ長は無制限で、キャッシュやブラウザの履歴に保存することもできず、安全性が高いです。 POST は GET よりも安定しており、信頼性が高くなります。
1. HTTP 仕様によれば、GET は情報取得に使用され、安全かつ冪等である必要があります。
(1). いわゆる安全とは、操作が情報を変更するのではなく、情報を取得するために使用されることを意味します。言い換えれば、GET リクエストには通常、副作用があってはなりません。つまり、データベース クエリと同様に、リソース情報を取得するだけであり、データの変更や追加は行われず、リソースのステータスには影響しません。
* 注: ここでのセキュリティの意味は、変更されていない情報のみを指します。
(2). べき等とは、同じ URL に対する複数のリクエストが同じ結果を返すことを意味します。ここで冪等の概念を再度説明します:
冪等 (冪等、冪等) は、抽象代数でよく見られる数学またはコンピューターサイエンスの概念です。
インポテンスにはいくつかの定義があります:
単項演算の場合、ある演算が範囲内のすべての数値に対してその演算を複数回実行する場合、その演算によって得られる結果は、その演算を 1 回実行して得られる結果と同じである場合、この演算が得られます。冪等であると言われます。例えば、絶対値演算は一例であり、実数の集合には、abs(a)=abs(abs(a))が存在する。
両眼演算の場合、演算に参加する 2 つの値が等しい場合、演算結果が演算に参加する 2 つの値と等しい場合、その演算は冪等であると言われることが要求されます2 つの数値の最大値を求めるなど、 の関数は実数の集合において冪等です (つまり、max(x,x) = x)。
上記の説明を読めば、GET 冪等の意味が理解できるはずです。
しかし、実際の適用では、上記の 2 つの規制はそれほど厳格ではありません。他人の記事を引用する例: たとえば、ニュース サイトのトップページは常に更新されます。 2 番目のリクエストは別のニュースのバッチを返しますが、常に最新のニュースを返すため、この操作は安全で冪等であると考えられます。基本的に、ユーザーがリンクを開いたときに、ユーザーの観点からリソースが変更されていないことを確認することが目標である場合、ユーザーはリソースが変更されていないことを確認できます。
2. HTTP 仕様によれば、POST はサーバー上のリソースを変更する可能性のあるリクエストを表します。上記の例の引用を続けます。ニュース Web サイトを例に挙げます。ニュースに対する読者のコメントは、コメントの送信後に異なるか変更されるため、POST を通じて実装する必要があります。
上記では、HTTP 仕様における GET と POST のいくつかの原則的な問題について簡単に説明しました。しかし、実際には、多くの人が HTTP 仕様に従っていません。この問題には次のような理由があります。
1. 多くの人は利便性を求めて、リソースを更新するときに GET を使用します。これは、POST が FORM (フォームに移動する必要があるため) です。 ）、少し面倒になります。
2. リソースの追加、削除、変更、確認は実際には GET/POST で完了でき、PUT や DELETE を使用する必要はありません。
3. もう一つは、初期の Web MVC フレームワーク設計者は意識的に URL を抽象リソースとして扱って設計していなかったため、より深刻な問題は、従来の Web MVC フレームワークは基本的に GET と POST の 2 つの HTTP メソッドしかサポートしていないのに、PUT と DELETE メソッドはサポートしていないことです。はサポートされていません。
* MVC の簡単な説明: MVC はもともとデスクトップ プログラムに存在していました。M はデータ モデルを指し、V はユーザー インターフェイスを指し、C はコントローラーを指します。 MVC を使用する目的は、M と V の実装コードを分離し、同じプログラムで異なる表現を使用できるようにすることです。
上記の 3 つの点は、典型的には古いスタイル (HTTP 仕様に厳密に準拠していない) を説明するものであり、アーキテクチャの発展に伴い、HTTP 仕様をサポートする新しいスタイルである REST (Representational State Transfer) が登場しました。ここでは詳しくは説明しません。「RESTful Web サービス」を参照してください。
原則的な問題について説明した後、GET と POST の違いを表面から見てみましょう:
1. GET によって要求されたデータは URL に追加されます (つまり、データは URL に配置されます)。 HTTP プロトコル ヘッダー)、URL を分割して ? でデータを転送し、login.action?name=hyddd&password=idontknow&verify=%E4%BD%A0%E5%A5%BD のようにパラメータを & で接続します。データが英字/数字の場合はそのまま送信し、スペースの場合は+に変換し、文字列を直接BASE64で暗号化すると、%E4 のようになります。 %BD%A0%E5%A5% BD。%XX の XX は、シンボルの 16 進数の ASCII 表現です。
POSTは、送信されたデータをHTTPパッケージの本文に配置します。
2.「GETメソッドで送信できるデータは最大1024バイトまでです。POSTには理論上制限がなく、より多くのデータを転送できます。最大はIIS4では80KB、IIS5では100KBです。」？ ? ！
上記の文は他の記事から転載しました。実際、これを言うのは間違っており、不正確です。
(1) まず、「GET で送信できるデータは 1024 バイトまでです」。GET は URL 経由でデータを送信するため、GET で送信できるデータの量は URL の長さに直接関係します。 。実際、URL にはパラメータの上限がなく、HTTP プロトコル仕様では URL の長さを制限しません。この制限は、特定のブラウザとサーバーによって課されます。 IE の URL の長さの制限は 2083 バイト (2K+35) です。 Netscape、FireFox などの他のブラウザの場合、理論上長さの制限はなく、制限はオペレーティング システムのサポートによって異なります。
この制限は、パラメータ値のデータ長だけではなく、URL 全体の長さであることに注意してください。 [参考資料 5 を参照]
(2) 理論的には、POST にはサイズ制限はなく、HTTP プロトコルの仕様では「POST には 80K/100K のサイズ制限がある」と言うのは不正確です。データ量。」 POST データに制限はありません。制限はサーバーのハンドラーの処理能力です。
ASP プログラムの場合、Request オブジェクトには各フォーム フィールドを処理する際のデータ長制限が 100K あります。ただし、Request.BinaryRead を使用する場合、そのような制限はありません。
これを発展させて、IIS 6.0では、Microsoftはセキュリティ上の理由から制限を強化しました。また、次の点にも注意する必要があります:
1) IIS 6.0 のデフォルトの ASP POST データ量は最大 200 KB で、各フォーム フィールドの制限は 100 KB です。
2).IIS 6.0でアップロードされるファイルのデフォルトの最大サイズは4MBです。
3) IIS 6.0のデフォルトの最大リクエストヘッダーは16KBです。
IIS 6.0以前にはそのような制限はありませんでした。 [参考5を参照]
つまり、上記の80Kと100Kは単にデフォルト値である可能性があります(注: IIS4とIIS5のパラメータを確認していません)が、それらは間違いなく自分で設定できます。 IIS の各バージョンにはこれらのパラメータのデフォルト値が異なるため、詳細については関連する IIS 構成ドキュメントを参照してください。
3. ASPでは、サーバーはRequest.QueryStringを使用してGETリクエストパラメータを取得し、Request.Formを使用してPOSTリクエストパラメータを取得します。 JSP では、 request.getParameter("XXXX") を使用して取得します。 jsp には request.getQueryString() メソッドもありますが、たとえば、 test.jsp?name=hyddd&password= を渡すのは面倒です。 hyddd、リクエストを使用して getQueryString() を取得します: name=hyddd&password=hyddd。 PHP では、$_GET と $_POST を使用して、それぞれ GET と POST でデータを取得できますが、$_REQUEST は GET リクエストと POST リクエストの両方でデータを取得できます。 JSP での request や PHP での $_REQUEST の使用には危険が潜んでいることに注意してください。これについては次回まとめた記事を書きます。
4. POST は GET よりも安全です。注: ここで説明するセキュリティは、上記の GET で説明した「セキュリティ」とは同じ概念ではありません。上記の「セキュリティ」の意味は、データの変更が行われないことだけであり、ここでのセキュリティの意味は、セキュリティの本当の意味です。たとえば、GET 経由でデータを送信する場合、ユーザー名とパスワードは URL にクリア テキストで表示されます。なぜなら、(1) ログイン ページがブラウザ キャッシュである可能性があり、(2) 他の人がブラウザ履歴を閲覧すると、他の人があなたのアカウントとパスワードを取得する可能性があるためです。さらに、GET を使用してデータを送信すると、クロスサイト リクエスト フォージェリ攻撃が発生する可能性もあります。
要約すると、Getはサーバーへのデータのリクエストであり、Postはサーバーへのデータの送信リクエストであり、FORM(フォーム)では、メソッドのデフォルトは「GET」です。送信メカニズムは異なります。一方が取得され、一方が送信されるわけではありません。
以上がpost リクエストと get リクエストの違いを解析するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
