Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more detail in Section 5.1 of [SEMANTICS]. As in HTTP/2, characters in field names MUST be converted to lowercase prior to their encoding. A request or response containing uppercase characters in field names MUST be treated as malformed (Section 4.1.3).
しかし HTTP2.0 への移行時、RFC 通りだと見られなくなるサイトが多かったことは想像に難くない。 RFC では「MUST be treated as malformed」だけど、その通りのブラウザなんてないんじゃないかな。 なお mozzila のサイト [mozilla.org]では HTTP1.1 時代のままなのか、区別しないと書かれている。
HTTP headers let the client and the server pass additional information with an HTTP request or response. An HTTP header consists of its case-insensitive name followed by a colon (:), then by its value. Whitespace before the value is ignored.
原因がダサすぎる (スコア:0)
HTTP/3で"Content-Length"のパースをcase sensitiveに行っていたから小文字の"content-length"を送られると応答の長さの取得に失敗するって…
Re: (スコア:-1)
ダサい原因のバグを作ったことがない人はコードを書いたことがない人だけ。君みたいにね。
Re: (スコア:-1)
聖人かな?
さすがにここまでダサいコードは書いたことないよ。
仮に書いたとして、自分のでもダサいって言うし、他人のもダサいって言うだけのこと。
事実を事実として捉えられない君とは違うから。
Re: (スコア:1)
何がダサいって規格違反のデータを考慮しなければならない現実かな…
Re:原因がダサすぎる (スコア:2, 興味深い)
Hypertext Transfer Protocol Version 3 (HTTP/3) [quicwg.org]
Field names are strings containing a subset of ASCII characters. Properties of HTTP field names and values are discussed in more detail in Section 5.1 of [SEMANTICS]. As in HTTP/2, characters in field names MUST be converted to lowercase prior to their encoding. A request or response containing uppercase characters in field names MUST be treated as malformed (Section 4.1.3).
ほんとだ、規格上は全部小文字にしろって書いてあるのか。
ただ、実体として定義されているフィールドからして [iana.org]は大文字混じっていて、なんだかなーという感じ。
Re: (スコア:0)
小文字にしなきなならない項目の名前を大文字混じりにするから余計混乱してんじゃん…
#規格策定の前提として企画が守られない場合を考慮しなければならないという暗黙のルールは守られない。考慮した結果無視することにしましただったらごめんなさい。
Re:原因がダサすぎる (スコア:1)
HTTP1.1 は case-insensitive [w3.org]
HTTP2.0 は 「header field names MUST be converted to lowercase」 [ietf.org]。
HTTP3.0 は#4186381で示されている通り、HTTP2.0 と同じ。
しかし HTTP2.0 への移行時、RFC 通りだと見られなくなるサイトが多かったことは想像に難くない。
RFC では「MUST be treated as malformed」だけど、その通りのブラウザなんてないんじゃないかな。
なお mozzila のサイト [mozilla.org]では HTTP1.1 時代のままなのか、区別しないと書かれている。
HTTP headers let the client and the server pass additional information with an HTTP request or response. An HTTP header consists of its case-insensitive name followed by a colon (:), then by its value. Whitespace before the value is ignored.
だからといって「Content-Length」を case-sensitive でチェックしているのは、RFC 関係なく開発側のミスとは思うけど。
Re: (スコア:0)
「規格に違反しているヘッダを読み込めるのはバグだ」なんて言うようになったりして。
Re: (スコア:0)
前に試してみたけど、規格違反のヘッダがそのまま読み込まれる事例はあるね。
551 not found
とかあり得ないステータスコードでも、エラーにならなかったり。
…どう表現するのが正しいのか、「http通信を完了できませんでした」みたいなことにはならず、
http通信としては通信が完了した上で、変なステータスコードがちゃんと入った状態になるという意味でのエラーにならない。
どこまで大きな数値を入れられるのか試してみたら、int型でオーバーフローするような挙動が見られたり、
どう数値変換したらそうなるのかよく分からない値に変換されたり。
バッファオーバーフローの脆弱性があるような処理はしてないだろうと思うけど、ちょっと気持ち悪かった。
際限なく受け付けられる訳でもないし、何されるか分からないし、規格違反は蹴るのが本当は正しいはず。
Re: (スコア:0)
551があり得ないって何で?
ステータスコードなんて随時拡張されてる物だよ
Re:原因がダサすぎる (スコア:1)
Re: (スコア:0)
551があるときー、551がないときー、ってCMは大阪外には通じないのか。
その地域限定ネタはともかく、4桁でも5桁でも「ステータスコードが変なだけの正しいhttp通信」として処理された。
3桁の整数と仕様に明記されてたはずだからこれはhttp通信ではない、と蹴らないとおかしい。