The preferred_address transport parameter contains an address and port for both IPv4 and IPv6. The four-byte IPv4 Address field is followed by the associated two-byte IPv4 Port field. This is followed by a 16-byte IPv6 Address field and two-byte IPv6 Port field. After address and port pairs, a Connection ID Length field describes the length of the following Connection ID field. Finally, a 16-byte Stateless Reset Token field includes the stateless reset token associated with the connection ID. The format of
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.
> However that function only looks at case-sensitive Content-Length:, but the header is in lowercase in the buffer, so we don't compute the content-length and leave it as zero. So we get here and get to the wrong branch, and fail to send the body and consume the rest of the buffer, so we loop indefinitely.
原因がダサすぎる (スコア:0)
HTTP/3で"Content-Length"のパースをcase sensitiveに行っていたから小文字の"content-length"を送られると応答の長さの取得に失敗するって…
Re:原因がダサすぎる (スコア:1)
「バグの90パーセントまでは、他人があきれるような愚かな理由でおこった。残る10パーセントは、当人さえあきれるような、より愚かな理由でおこった」
Re: (スコア:0)
詳しそうな人が居そうなのでおしえて。HTTP/3は、UDPで445のポートの開放が必要とあるから楽天モバイル等のグローバルアドレスが与えられないところでは使えない？ 普及が進んでHTTP/3だらけになるとつなげなくなるの？
Re: (スコア:0)
ポート開放が必要なのはサーバ側でしょ？
Re: (スコア:0)
そう言ってるのってさくらのSSLのコラム [sakura.ad.jp]だけしか見当たらないんだけど……
あくまで意図的にFWで通信カットしている場合の話であって、楽天モバイルのようなCGNATでは普通に通るはず……というか現に手元の楽天モバイル回線でGoogleのサイト開いたときにHTTP/3通信できてますよ
Re: (スコア:0)
質問した時445と書いて申し訳ありませんでした。
Re: (スコア:0)
UDPだからポート解放しないと通信できませんよ。TCPとUDPの違いを勉強してから出直してきてください。
何を言っておるのかね。UDPでも普通にNAPTできる。
そもそも、今ゲーム業界で主流のUDPホールパンチングとかはNAPTされることが前提の技術なんだが。
Re: (スコア:0)
クライアントのポートが443固定でないと通信できないとかちょっと信じられないんだが…
Re: (スコア:0)
内側から通信を始めたら、今時の普通のご家庭用NATルータを普通の設定で使ってるなら空気を読んで必要な分だけ、その「ポート開放」に該当する処理を自動でしてくれる。
UDPの勉強で止まらず、NATの歴史を勉強してみよう。
Re: (スコア:0)
書いた人ではないが、多分
クライアント側の「開放」って意味が
クライアント側はサーバーのUDP443へ送信できるようにするのか、
クライアント側がUDP443で受信できるようにするのか、どっちの意味で「開放」って使ってるのかが食い違っているかと
Re: (スコア:0)
NAPT がまだ生き残っていることを考えると、まずあり得ないですね。
RFC9000 [rfc-editor.org]を眺めた感じ、ちゃんと異なるポートを指定するための定義がありました。
The preferred_address transport parameter contains an address and port for both IPv4 and IPv6. The four-byte IPv4 Address field is followed by the associated two-byte IPv4 Port field. This is followed by a 16-byte IPv6 Address field and two-byte IPv6 Port field. After address and port pairs, a Connection ID Length field describes the length of the following Connection ID field. Finally, a 16-byte Stateless Reset Token field includes the stateless reset token associated with the connection ID. The format of
Re:原因がダサすぎる (スコア:1)
クライアントのポートが固定ということになると、
・クライアント側のPC上で、HTTP3/QUICを使うソフトウェア(ブラウザ)は一つだけに限定される(ChromeとFirefoxを同時起動しても、HTTP3を使えるのは片方だけ)
どころか、
・キャリアグレードNATで複数の回線利用者がIPアドレスを共有する場合、HTTP3を使えるのはその中の一人だけ
になってしまうんですよね。「そんなわけないだろ」と気づいてほしいところ。
Re: (スコア:0)
ですよねぇ
「詳しそうな人が居そうなのでおしえて。」の流れで
詳しそうで何も知らない回答者なのか
質問者が頑なに間違いを信じ続けてるのか
どっちかも分かり辛い流れですが
謝に観てみると意図的にsmb:445開けさせようとしているとも取れますし
これ以上相手にせずマイナスもでが正しい対処な気がします
Re: (スコア:0)
その解釈の場合、「クライアント、サーバーともに」とは書かないと思うんだよな。そこまでわかっているなら方向を明記する。
Re: (スコア:0)
あー。そういうことですか。ようやく理解できた気が。ありがとうございます。
どうやったらこんな意味不明な食い違いが起こるのかと思っていたけど。
「クライアント側のネットワークのファイヤーウォール等でサーバ側 UDP 443ポートへの接続を制限している場合に通信できない。」
みたいな当たり前すぎて誰も気にしてないことを
「クライアント側のUDP 443ポートの開放が必要。」
みたいな話になっているのか。
Re: (スコア:0)
あるいは、サーバ側とクライアント側でポート番号を揃えないといけないと思い込んでいるのかも。
# ウェブ環境変数チェッカー [pdata.jp]なんかにアクセスしてみればわかるけど、クライアント側のポート番号(REMOTE_PORT)はサーバ側のポート番号(80)とは一致しない
Re:原因がダサすぎる (スコア:1)
ググったら、クライアントとサーバ両方443ポートを開放する必要があると解説しているページがいくつか見つかった [google.com]んですが、
フィッシング対策協議会(JPCERT運営) [antiphishing.jp]とかさくらのSSL コラム [sakura.ad.jp]とか大御所っぽいところがやらかしてるので、そこから伝播してるのかも
Re: (スコア:0)
企業などでセキュリティのために不要なポートを閉じている場合は注意する必要があります。
クライアントのポート開放って送信の話じゃねえかな。
企業なんかだと余計な通信できないように特定サービス以外アクセスできないようにしてんじゃん。
Re: (スコア:0)
クライアントとサーバ、両方ともUDP/445の開放が必要ですよ
445はsmbでファイル共有
脆弱性出してどうする
元コメからマイナスもでで鎮めるほうが良さげ
ちなみにUDP 443な
いままでTCP 443でリスポンス待ちだったのを
投げっぱなしUDPでやっちゃおうぜその方が早くなるし
ってやつ
Re: (スコア:0)
> 普及が進んでHTTP/3だらけになるとつなげなくなるの？
HTTP/1やHTTP/2を一切サポートしないクライアントが普及すればそうなるけど、既存のHTTPが廃止や非推奨になるとは考えにくいので杞憂と言っていいと思う。
Re: (スコア:0)
意訳:そのうち旧規格が廃止されて阿鼻叫喚または旧規格が廃止できず後々問題になるのどっちか。
Re: (スコア:0)
廃止もされず問題にもならず、が一番ありそうなのでどうでもいい
Re: (スコア:0)
HTTP/3は、UDPで445のポートの開放が必要とあるから楽天モバイル等のグローバルアドレスが与えられないところでは使えない？
きっと大丈夫ですよ
smbで全世界で共有フォルダが開放されるのでしたらどうとでもなりますって
# 恐ろしい間違いするなぁ
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通信ではない、と蹴らないとおかしい。
全くの逆で Firefox が規格通りのデータを処理できなかった (スコア:2, すばらしい洞察)
何がダサいって規格違反のデータを考慮しなければならない現実かな…
全くの出鱈目です。
https://bugzilla.mozilla.org/show_bug.cgi?id=1749957#c5 [mozilla.org]
> However that function only looks at case-sensitive Content-Length:, but the header is in lowercase in the buffer, so we don't compute the content-length and leave it as zero. So we get here and get to the wrong branch, and fail to send the body and consume the rest of the buffer, so we loop indefinitely.
規格上は "content-length" としなければならない（現実にはそうなっていないケースも多いが）のですが、
Firefox は case-sensitive で "Content-Length" でなければ正しく処理できませんでした。
つまり、Firefox は規格通りのデータを処理できなかったのです。
100% Firefox が悪いです。
Re: (スコア:0)
完全に理解してそう...