http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2によると、HTTP OPTIONSリクエストに関してこれまでに言及された唯一の応答は200です。ただし、次のような場合があるようです。 content-lengthは0であり、204の方が適切です。HTTP OPTIONSリクエストが204を返すのは適切ですか？
17458 次
3 に答える
18
RFC2616は次のように述べています。
200の応答が必要です...
..。
応答本文が含まれていない場合、応答にはフィールド値が「0」のContent-Lengthフィールドが含まれている必要があります。
これは確かに、200が段落全体に適用されるのか、最初の文のみに適用されるのかを不明確にします。安全にプレイしたい場合は、MUSTを優先させます（コストはそれほどかかりません）。
RFC2616を廃止したRFC7231は、文言を次のように変更しました。
OPTIONSへの正常な応答を生成するサーバーは...
..。
ペイロード本体が応答で送信されない場合、サーバーは値が「0」のContent-Lengthフィールドを生成する必要があります。
これにより、最後の文が一般的な意味で2xxステータスに適用され、MUSTが優先されます。
したがって、Content-Lengthを送信する必要があります。ただし、Content-Lengthを204で送信することはできません。
RFC 2616は、次のように述べています。
リクエストにメッセージ本文が存在することは、Content-LengthまたはTransfer-Encodingヘッダーフィールドを含めることで通知されます。
...すべての1xx（情報）、204（コンテンツなし）、および304（変更されていない）応答には、メッセージ本文を含めてはなりません（MUSTNOT）。
また、RFC7230はこれも明確にしています。
サーバーは、ステータスコードが1xx（情報）または204（コンテンツなし）の応答でContent-Lengthヘッダーフィールドを送信してはなりません（MUSTNOT）。
とにかく、それが私がそれを理解する方法です。
于 2015-07-06T21:37:11.840 に答える
9
はい、204を返すことができます。または400。または404。メソッドが返すことができるステータスコードに関する一般的な制限はありません。
また、RFC 2616の確認をやめるときが来たことにも注意してください。http： //trac.tools.ietf.org/wg/httpbis/trac/wikiを参照してください。
于 2013-02-05T08:49:29.503 に答える
4
既存の言語内で、RFC7230§3.3.2Content-Length間の明らかな矛盾に対する唯一の解決策：
「サーバーはContent-Length、ステータスコードが1xx（情報）または204（コンテンツなし）の応答でヘッダーフィールドを送信してはなりません。」</ p>
「応答でペイロード本体を送信しない場合、サーバーはContent-Length値が「0」のフィールドを生成する必要があります。」</ p>
OPTIONSリクエストに対する204の応答すべてを禁止することです。これは意図されていなかったようですので、正誤表を提出しました。後者のステートメントは、 draft-ietf-httpbis-semantics-06のRFC 7231から削除されたため、204応答（フィールドなし）が明確に許可されるようになりました。Content-Length
于 2019-08-12T02:40:18.090 に答える