3

HTML フォームによって送信されないリクエストの場合、HTTP はリクエストの Content-Type をファイル以外のアップロード用に application/x-www-form-urlencoded に制限しますか、それともその MIME タイプは「正しい」/標準/意味的に他のもので意味がありますか?仕方？

たとえば、PHP はコンテンツを $_POST に自動的に解析します。これは、サーバーが x-www-form-urlencoded を予期していることを示しているようです。一方、Ajax を使用して、HTTP 要求コンテンツで JSON オブジェクトを送信し、Content-Type を application/json に設定することもできます。少なくとも一部のサーバー テクノロジ (WSGI など) は、それを解析しようとせず、代わりに元の形式でスクリプトに提供します。

HTTP のすべてのサーバー実装に確実に準拠するには、RESTful API の POST および PUT 要求でどの MIME タイプを使用する必要がありますか? SOAP や JSON-RPC などのテクノロジは、意図したとおりに HTTP を使用するのではなく、HTTP を介してプロトコルをトンネリングするため、無視しています。

4

1 に答える 1

5

簡潔な答え

HTTP メッセージ エンティティ本体を最もよく表すコンテンツ タイプを指定する必要があります。

長い答え

たとえば、PHP は自動的にコンテンツを $_POST に解析します。これは、サーバーが x-www-form-urlencoded を予期していることを示しているようです。

サーバーは「期待」していませんx-www-form-urlencoded。PHP は、開発者の作業を簡素化するために、フォームでエンコードされたエンティティ本体をスーパーグローバルに解析し、かつエンティティ本体が実際に urlencoded キーと値の文字列である$_POST場合にのみ実行します。配列を生成するためContent-Type: x-www-form-urlencodedに到着するメッセージについても同様のプロセスに従います。これらのスーパーグローバルは役に立ちますが、残念ながら名前が付けられており、実際の HTTP トランザクションに関して実際に何が起こっているのかわかりにくくなっています。Content-Type: multipart/form-data$_FILES

HTTP のすべてのサーバー実装に確実に準拠するには、RESTful API の POST および PUT 要求でどの MIME タイプを使用する必要がありますか?

HTTP メッセージ エンティティ本体を最もよく表すコンテンツ タイプを指定する必要があります。常に公式の HTTP 仕様に準拠してください。そうすれば間違いはありません。RFC 2616 Sec 7.2.1から(強調を追加):

エンティティ本体を含む HTTP/1.1 メッセージには、その本体のメディア タイプを定義する Content-Type ヘッダー フィールドを含める必要があります。メディア タイプが Content-Type フィールドで指定されていない場合に限り、受信者は、リソースの識別に使用される URI のコンテンツおよび/または拡張子の検査によって、メディア タイプを推測しようとする場合があります。メディア タイプが不明のままである場合、受信者はそれを「アプリケーション/オクテット ストリーム」タイプとして扱う必要があります (SHOULD)。

主流のサーバー技術はすべて、これらのルールに従います。思慮深い Web アプリケーションは、Content-Typeヘッダーが正しい場合とそうでない場合があるため、ヘッダーを信頼しません。メッセージの発信者は、完全に偽の値を自由に送信できます。通常、Content-Typeヘッダーは事前検証手段としてチェックされますが、コンテンツは実際のデータを解析することによってさらに検証されます。たとえば、JSON データを REST サービスに PUT している場合、エンドポイントは最初に を送信したことを確認しますContent-Type: application/jsonが、実際にはメッセージのエンティティ ボディを解析して、それが実際に有効な JSON であることを確認します。

于 2012-08-25T17:32:43.667 に答える