取得し、差のポストhttpリクエスト
序文：
私たちは今、あなたの母親ビットの度合いであり、最も違いを確認し、おそらく：
「上院を通過する書き込み、POSTリクエストのボディへのURLのパラメータを取得します。」
「パラメータを取得URLに直接表示されるので、GET、POSTは、安全ではありません」
「長さが限られているURLに送信されるリクエストパラメータを取得し、何のPOSTではありません」
しかし、真実はその権利がありますか？！！！真実は常に唯一のものです！！！
先分析一波：
データ転送をGETとPOSTする方法は重要ではありませんか？？
GETとPOSTは、HTTPプロトコルで定義されています。その方法とどのようにアプリケーション層のデータ伝送には関係ありません。要件がないHTTP POSTリクエストは、本体内に配置する必要がありますこのように、、、URLのGETは、内部に配置する必要があります。
HTMLの規格では、同様の定義を持っています。しかし、これはHTTPプロトコルを使用するための唯一のHTML標準的な慣習です。それは区別なくその規範です。
さて、この文は、それから来ますか？ブラウザや他のソフトウェアが種々達成ので、我々が知っているように、それは現象となり、体重の参加とURLのパラメータの受け渡し、POSTを使用GET。
HTTPプロトコルは、GETとPOSTの長さに制限はありませんか？？
HTTPプロトコル、HTTPリクエスト・ヘッダーとリクエストのボディが全く長さを必要としないことは明らか。
URLの長さの制限については、原因の2つの側面があります。
1.ブラウザ。IE URLは2048の文字の長さに制限されると言われています。しかし、私の知る限り、Firefoxの長さ以上10Wサポートがあります。
2.サーバー。URL自体を加工するロングサーバは、悪意のある攻撃からはもちろんのこと、負担のですか？そのため、考慮すべきセキュリティ、安定性および他の側面のためのほとんどのサーバは、URLの長さの制限を与えます。
しかし、この制限は、POSTが問題ではありませんすべてのHTTP、GETの要求があります。
安全と危険なGET、POSTは一切関係がありませんか？？
問題は、まずあなたがオブジェクト指向を確認する必要があります。
例えば：
1.あなたはこのURL私のお母さんとお父さんを見たいと思って、あなたは安全だと感じますか？
2.あなたが今ちょうどこのリンクをテストするために、主要な機能のテストエンジニアを作るために開始され、あなたは安全だと感じますか？
3.あなたは今、あなたは安心、セキュリティテストエンジニアGETリクエストを見てみたいですか？
だから、人々のさまざまなグループのために定義され、セキュリティが異なることになります。
「あなたは層によって剥離層、私の心の層に喜んでいる場合、あなたは私の最も押し下げ最も深い秘密です、あなたは驚かれることでしょう。」
GETとPOSTの皮の後、彼らの本質は、TCPのリンク、および非差別的です。
しかし、HTTPの規定とブラウザ/サーバの制限のために、アプリケーションのプロセスにいくつかの違いを反映して、それらを引き起こして。
だから、最終的には何の真実はそれを何ですか？
取得は、TCPパケットを生成し、ポストは、2つのTCPパケットを生成します。
GETリクエストのために、ブラウザは、HTTPヘッダとデータは、一緒にサーバ応答200（リターンデータ）を送信します。
POSTのために、ブラウザはまずヘッダ、サーバ応答100（継続）を送信し、サーバー200（リターンデータ）に応答して、データを送信します。