28

HTTP/1.1Accept要求ヘッダーは、RFC 2616 のセクション 14.1で指定されています。

構文は次のようになります。

   Accept         = "Accept" ":"
                    #( media-range [ accept-params ] )

#セクション 2.1に従って、数字なしでゼロ以上を示します。ただし、セクション 14.1 では、空のヘッダーを解釈する方法については何も述べていません。これは、セクション 14.2 とは対照的です。セクション 14.2では、が使用されるだけでなく( one or more )、空のヘッダーのケースも指定されています。これはちょっと奇妙です。リクエストヘッダーを扱う他のいくつかのセクションも、空の値の特殊なケースに固有です。AcceptAccept-Encoding1#Accept-Encoding

空のヘッダーを 存在Acceptしないヘッダーと同等に扱うべきですか? 私が見逃したこれに関する公式リソースはありますか？ Accept

4

3 に答える 3

33

RFC2616 Sec4.2から:

各ヘッダー フィールドは、名前の後にコロン (":") とフィールド値が続く形式で構成されます。

一見すると、空のヘッダー値を指定するメッセージは、形式が正しくない非準拠のカテゴリに分類されるように見えます。ただし、 RFC2616 Sec2.1で概説されている拡張 BNF フォームは、次のことを示しています。

「#element」は、ゼロを含む任意の数を許可します

これは、Accept ヘッダー値を指定するために使用される宣言であるため、空の値が有効であるように見えます。

仕様からの次の指示により、空のヘッダーと空白のみのヘッダーを解析すると問題が発生する可能性があります。

field-content には、先頭または末尾の LWS は含まれません。つまり、field-value の最初の非空白文字の前、または field-value の最後の非空白文字の後に発生する線形空白です。このような先頭または末尾の LWS は、フィールド値のセマンティクスを変更せずに削除できます。フィールド値を解釈する前、またはメッセージを下流に転送する前に、フィールドコンテンツ間で発生する LWS を単一の SP に置き換えることができます (MAY)。

私見、空のヘッダーを送信することは完全に無意味です。パーサーがこれらのヘッダーを正しく解析しない可能性があります。伝統的に、準拠していないコンポーネントを扱うときにこのような制限を回避したい人は、次のように「疑似空」の値を指定していました。

X-MyCustomHeader: ""

ヘッダー フィールドが何らかの形式のブール スイッチとして送信されたことを単純に検証したい場合は、空の値ではなく、上記のようなプレースホルダー値を送信することを検討してください。

アップデート

質問に直接答えるのがあまり明確ではなかったと思います。空の Accept ヘッダーの場合、実際には 2 つのオプションがあります。

  • 応答を送信し406 Not Acceptableて、空の Accept 値に対してコンテンツ タイプを提供しないことをクライアントに通知します (当然)。

これは正当化されますが、 RFC2616 Sec14.1では必須ではありません。

Accept ヘッダー フィールドが存在し、サーバーが Accept フィールド値の組み合わせに従って受け入れ可能な応答を送信できない場合、サーバーは 406 (受け入れられない) 応答を送信する必要があります。

  • または、これは必須ではなく、ユーザーがコンテンツ タイプを受け入れない可能性が非常に高いため(そうでなければ、なぜわざわざリクエストを送信するのでしょうか?) ... 空のAccept:値を処理することをお勧めします (メッセージの拒否が「オプション) と同じAccept: */*。
于 2012-08-26T16:49:38.987 に答える
6

https://www.rfc-editor.org/rfc/rfc7231#section-5.3.2によると:

Accept ヘッダー フィールドのないリクエストは、ユーザー エージェントが応答で任意のメディア タイプを受け入れることを意味します。

Accept存在しないヘッダーは として扱う必要があり*/*ます。

于 2016-01-04T13:14:38.773 に答える