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).
原因がダサすぎる (スコア: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: (スコア:0)
前に試してみたけど、規格違反のヘッダがそのまま読み込まれる事例はあるね。
551 not found
とかあり得ないステータスコードでも、エラーにならなかったり。
…どう表現するのが正しいのか、「http通信を完了できませんでした」みたいなことにはならず、
http通信としては通信が完了した上で、変なステータスコードがちゃんと入った状態になるという意味でのエラーにならない。
どこまで大きな数値を入れられるのか試してみたら、int型でオーバーフローするような挙動が見られたり、
どう数値変換したらそうなるのかよく分からない値に変換されたり。
バッファオーバーフローの脆弱性があるような処理はしてないだろうと思うけど、ちょっと気持ち悪かった。
際限なく受け付けられる訳でもないし、何されるか分からないし、規格違反は蹴るのが本当は正しいはず。
Re: (スコア:0)
551があり得ないって何で？
ステータスコードなんて随時拡張されてる物だよ
Re:原因がダサすぎる (スコア:1)