1641

HTTP GETリクエストでは、パラメーターはクエリ文字列として送信されます。

http://example.com/page ?parameter=value&also=another

HTTP POST要求では、パラメーターは URI と共に送信されません。

値はどこにありますか? リクエストヘッダーで？リクエスト本文で？それはどのように見えますか？

4

9 に答える 9

1382

値は、コンテンツタイプが指定する形式で、リクエスト本文で送信されます。

通常、コンテンツタイプはapplication/x-www-form-urlencodedであるため、リクエスト本文はクエリ文字列と同じ形式を使用します。

parameter=value&also=another

フォームでファイルのアップロードを使用する場合は、multipart/form-data代わりに別の形式のエンコーディングを使用します。もっと複雑ですが、通常はどのように見えるかを気にする必要がないので、例を示しませんが、それが存在することを知っておくとよいでしょう。

于 2013-01-27T19:32:10.950 に答える
452

コンテンツは HTTP ヘッダーの後に配置されます。HTTP POST の形式は、HTTP ヘッダーの後に空白行が続き、その後に要求本文が続きます。POST 変数は、本体にキーと値のペアとして格納されます。

これは、以下に示す HTTP Post の生のコンテンツで確認できます。

POST /path/script.cgi HTTP/1.0
From: frog@jmarshall.com
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32

home=Cosby&favorite+flavor=flies

これは、 Fiddlerなどのツールを使用して確認できます。このツールを使用して、生の HTTP 要求とネットワーク経由で送信される応答ペイロードを監視できます。

于 2013-01-27T19:21:26.210 に答える
439

簡単な答え: POST リクエストでは、値はリクエストの「本文」で送信されます。Web フォームでは、ほとんどの場合、application/x-www-form-urlencodedまたはのメディア タイプで送信されmultipart/form-dataます。Web リクエストを処理するように設計されたプログラミング言語またはフレームワークは、通常、そのようなリクエストで「The Right Thing™」を実行し、すぐにデコードされた値に簡単にアクセスできるようにします ( PHPや$_REQUESTPythonなど)。$_POSTcgi.FieldStorage()flask.request.form

違いを理解するのに役立つかもしれません ;)

GETとPOSTrequestsの違いは、主にセマンティックです。また、それらは異なる方法で「使用」されます。これは、値がどのように渡されるかの違いを説明しています。

GET (関連する RFC セクション)

リクエストを実行するときGET、サーバーにエンティティの 1 つまたはセットを要求します。クライアントが結果をフィルタリングできるようにするために、URL のいわゆる「クエリ文字列」を使用できます。の後の部分がクエリ文字列です?。これはURI 構文の一部です。

したがって、アプリケーション コード (リクエストを受信する部分) の観点から、これらの値にアクセスするには、URI クエリ部分を検査する必要があります。

キーと値は URI の一部であることに注意してください。ブラウザーは、URI の長さに制限を課す場合があります。HTTP 標準では、制限はないと規定されています。しかし、これを書いている時点では、ほとんどのブラウザーがURI を制限しています (特定の値はありません)。サーバーに新しい情報を送信するためにGETリクエストを使用しないでください。特に大きなドキュメントではありません。POSTここでorを使用する必要がありますPUT。

POST (関連する RFC セクション)

リクエストを実行するときPOST、クライアントは実際には新しいドキュメントをリモート ホストに送信しています。したがって、クエリ文字列は (意味的に) 意味がありません。これが、アプリケーション コードでそれらにアクセスできない理由です。

POSTもう少し複雑です（そしてより柔軟です）：

POST リクエストを受信するときは、常に「ペイロード」、つまり HTTP 用語でメッセージの本文を期待する必要があります。メッセージ本文自体は、標準(私が知る限り、おそらくアプリケーション/オクテット ストリーム?) 形式がないため、ほとんど役に立ちません。本文の形式は、Content-Typeヘッダーによって定義されます。で HTMLFORM要素を使用する場合method="POST"、これは通常application/x-www-form-urlencoded. ファイルのアップロードを使用する場合、もう 1 つの非常に一般的なタイプはmultipart/form-dataです。しかし、それは何でもありえます。text/plainapplication/jsonapplication/octet-stream

いずれにせよ、アプリケーションで処理できない でPOSTリクエストが行われた場合は、 status-codeを返す必要があります。Content-Type415

ほとんどのプログラミング言語 (および/または Web フレームワーク) は、メッセージ本文を最も一般的なタイプ ( application/x-www-form-urlencoded、multipart/form-dataまたは などapplication/json) から/へとデコード/エンコードする方法を提供します。それは簡単です。カスタム型には、もう少し作業が必要になる可能性があります。

例として標準の HTML フォーム エンコード ドキュメントを使用すると、アプリケーションは次の手順を実行する必要があります。

  1. Content-Typeフィールドを読む
  2. 値がサポートされているメディア タイプのいずれでもない場合は、415ステータス コードを含む応答を返します
  3. それ以外の場合は、メッセージ本文から値をデコードします。

繰り返しになりますが、PHP などの言語や、他の一般的な言語の Web フレームワークは、おそらくこれを処理します。これに対する例外は415エラーです。アプリケーションがどのコンテンツ タイプをサポートするか、またはサポートしないかを予測できるフレームワークはありません。これはあなた次第です。

PUT (関連する RFC セクション)

リクエストは、リクエストPUTとほぼ同じ方法で処理されPOSTます。大きな違いは、POSTリクエストはサーバーに新しいリソースの作成方法 (および作成する場合) を決定させることになっていることです。歴史的には (現在は廃止された RFC2616 以降、リクエストが送信された URI の「従属」(子) として新しいリソースを作成することでした)。

対照的に、リクエストは、正確にその URI に、正確にその内容でPUTリソースを「預ける」ことになっています。それ以上でもそれ以下でもありません。アイデアは、クライアントが完全なリソースを「PUT」する前に作成する責任があるということです。サーバーは、指定された URL でそのまま受け入れる必要があります。

そのため、既存のリソースを置き換えるためPOSTにリクエストを使用することは通常ありません。リクエストは、作成と置換の両方を実行できます。PUT

サイドノート

追加のデータをリモートに送信するために使用できる「パス パラメータ」もありますが、それらは非常に一般的ではないため、ここでは詳しく説明しません。ただし、参考までに、RFC からの抜粋を次に示します。

階層パスのドット セグメントは別として、パス セグメントは一般的な構文では不透明と見なされます。URI 生成アプリケーションは、セグメントで許可されている予約文字を使用して、スキーム固有または逆参照ハンドラー固有のサブコンポーネントを区切ることがよくあります。たとえば、セミコロン (";") と等号 ("=") の予約文字は、そのセグメントに適用されるパラメーターとパラメーター値を区切るためによく使用されます。コンマ (",") 予約文字は、同様の目的でよく使用されます。たとえば、ある URI プロデューサーは「name;v=1.1」などのセグメントを使用して「name」のバージョン 1.1 への参照を示す場合がありますが、別の URI プロデューサーは「name,1.1」などのセグメントを使用して同じことを示す場合があります。パラメータの型は、スキーム固有のセマンティクスによって定義できます。

于 2014-11-03T15:54:48.490 に答える
63

ブラウザの URL バーに直接入力することはできません。

たとえば、ライブ HTTP ヘッダーを使用して、インターネット上で POST データがどのように送信されるかを確認できます。結果はそのようなものになります

http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1

Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=password

それが言うところ

Content-Length: 30
    username=zurfyx&pass=password

投稿値になります。

于 2013-01-27T19:29:32.383 に答える
20

一部の Web サービスでは、要求データとメタデータを別々に配置する必要があります。たとえば、リモート関数は、署名されたメタデータ文字列が URI に含まれていることを期待する場合がありますが、データは HTTP ボディにポストされます。

POST リクエストは意味的に次のようになります。

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)

name    id
John    G12N
Sarah   J87M
Bob     N33Y

Content-Typeこのアプローチは、Web サーバーの「解析命令」である単一を使用して、QueryString と Body-Post を論理的に組み合わせます。

注: HTTP/1.1 は、左側が#32(スペース) で、#10右側が (改行) で囲まれています。

于 2015-07-31T14:01:37.767 に答える
20

HTTP POST のフォーム値は、クエリ文字列と同じ形式で、リクエスト本文で送信されます。

詳細については、仕様を参照してください。

于 2013-01-27T19:20:19.700 に答える
12

まず、 と を区別しましょうGET。POST

Get:サーバーに対して行われるデフォルトのHTTP要求であり、サーバーからデータを取得するために使用され、一意のリソースを取得するためにの後?に続くクエリ文字列が使用されます。URI

これがフォーマットです

GET /someweb.asp?data=value HTTP/1.0

渡されたdata=valueクエリ文字列値は次のとおりです。

POST:サーバーにデータを安全に送信するために使用されるため、必要なものはすべて、これがPOSTリクエストの形式です

POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename

GET よりも POST を使用する理由

サーバーに送信される値ではGET、通常、クエリ文字列のベース URL に追加されますが、これには 2 つの結果があります。

  • リクエストはパラメータとともにブラウザのGET履歴に保存されます。そのため、パスワードは暗号化されずにブラウザーの履歴に残ります。これは、かつて Facebook にとって深刻な問題でした。
  • 通常、サーバーには a の長さに制限URIがあります。送信されるパラメーターが多すぎる場合は、受信する可能性があります414 Error - URI too long

投稿リクエストの場合、フィールドからのデータが代わりに本文に追加されます。リクエスト パラメータの長さが計算され、コンテンツ長のヘッダーに追加され、重要なデータが URL に直接追加されることはありません。

Google Developer Tools のネットワーク セクションを使用して、サーバーへのリクエストがどのように行われるかについての基本情報を確認できます。

、、Request Headersなどの値をいつでも追加できます。Cache-ControlOriginAccept

于 2018-07-19T07:04:18.180 に答える