0

PUT、POSTおよびJSON 形式PATCHの両方でリソース表現を受け入れることができる Web アプリケーションを構築しています。x-www-form-urlencodedリクエスト本文を別の形式で受信した場合は、応答を送信したいと思います。さらに、受け入れる形式を宣言する追加データも送信します (応答の必須ヘッダー415と同様の方法で)。HTTP 406 および 415 エラー コードでの1 つの回答で、そのようなメカニズムが定義されているかどうかを回答者が知らなかったのを見たことがあります。405Allow:

Accept:リクエストヘッダーとして定義されていますが、そのまま使用したいと思います。この応答に再利用するのが最も適切なようです。人々は同意しますか？誰かがより良い提案をしていますか?

編集:以来、これに関する標準があるかどうかを具体的に尋ねる「415サポートされていないメディアタイプ」を送信するときに、サポートされているメディアタイプを指定することを発見しました。正解で受け入れられた回答は基本的にno でしたが、回答者も私と同じ考えを持っていました。Accept はこの情報を提供するために使用するのに適したヘッダーです。これにより、 Julian ReschkeからHTTP ワーキング グループにメッセージが送られ、応答でヘッダーを送信する意味を定義する必要があるかどうか尋ねられました。そのメールには 1 件の返信しかありませんでした。Accept:

Accept ヘッダーの送信が許可されているかどうかを尋ねているわけではないことに注意してください。任意のヘッダーをどちらの方向にも送信できますが、仕様で定義されているものだけが仲介者にとって意味(セマンティクス) を持ちます。また、プレフィックスが付けられていない予期しないヘッダーwithX-は、将来のバージョンの HTTP と競合する可能性があります。これは気にしません。

4

3 に答える 3

1

あなたが言ったようにAccept、リクエストヘッダーです。応答で使用するのは間違っています。

ウィキペディアを引用すると、

コンテンツ ネゴシエーションは、HTTP 仕様で定義されたメカニズムであり、同じ URI で異なるバージョンのドキュメント (またはより一般的にはリソース表現) を提供できるようにするため、ユーザー エージェントは、その機能に最適なバージョンを指定できます。

そのため、リクエストでどのメディア タイプを使用できるかを指定するのはクライアントAcceptです。サーバーがこのメディア タイプを配信できない場合、彼は で応答し406 Not Acceptableます。

クライアントは、要求されたリソースの返された表現を処理できなければならないため、理解できるメディア タイプを指定する必要があります。複数のメディア タイプを指定できます。

Accept: application/json, application/xml, x-www-form-urlencoded

クライアントが本当にメディア タイプを受け入れたい場合は、次のように設定できます。

Accept: */*

サーバーはContent-Type、そのような要求に対しても適切な応答ヘッダーを設定します。

于 2012-11-08T08:03:38.927 に答える
0

認識されない Content-Type を受け取ったのは、現在サービスにクライアントを実装している開発者からのものである可能性が最も高いでしょう。サーバーがサポートされているコンテンツ タイプをアドバタイズするメカニズムが存在しないため、サポートしているタイプをメッセージ本文に記載することもできます。

于 2012-11-08T08:19:11.220 に答える
0

これを行うための標準的なメカニズムについては知りませんが、Alternates ヘッダーhttp://www.ietf.org/rfc/rfc2295.txtの目的を少し変更して、必要なことを行うことができる場合があります。

于 2012-11-09T12:33:32.733 に答える