RFC 9112 Quiz

**Explanation:** **Terms:** header section, empty line, CRLF. HTTP/1.1では, headerの終端とbodyの開始は空行で区切られる. **RFCを読むときの見方:** RFC 9112 では, まず「どこで header section が終わるか」を固定してから, 次に body 長の決め方へ進みます. 境界が曖昧だと, 同じ bytes を見ても proxy と origin で解釈がずれてしまいます. **Correct (C):** 最後のheader fieldの後に, CRLFだけの空行が来ることでheader sectionが終了します. ここを基準に body の開始位置が決まるので, line ending の扱いは単なる書式ではなく framing そのものです. **Options:** - A (incorrect): Content-Lengthはbodyの長さのヒントで, header sectionの終端ではない. - B (incorrect): HTTP/1.1はCRLFを行終端として定義している. LF-onlyは互換性や安全性の問題になり得る. - C (correct): 空行が区切りになる. **Related:** 終端解釈のズレはrequest smugglingの原因になり得ます. だから RFC 9112 は, 些細に見える改行規則をかなり丁寧に定義しています.

**Explanation:** **Terms:** message framing, Content-Length, Transfer-Encoding, chunked. HTTP/1.1は複数のframing手段を持ち, headerの組み合わせと優先順位で決まる. **Correct (C):** Transfer-Encodingがある場合の扱い, Content-Lengthの妥当性, そして場合によってはconnection closeで区切る, という順序規則がある. **Options:** - A (incorrect): Transfer-Encodingがframingを支配するケースがある. Content-Length単独依存は危険. - B (incorrect): closeは最後の手段で, persistent connectionを壊す. - C (correct): 規則に従って一意に決める. **Related:** 中間者とendpointで解釈が違うとrequest smugglingが起きる.

**Explanation:** **Terms:** chunked coding, terminator. chunked transfer codingはchunkの連続でbodyを表現する. **Correct (B):** 終端はサイズ0のchunkで示され, その後に最終CRLFとoptionalなtrailer fieldが続く. **Options:** - A (incorrect): closeはchunkedの通常の終端ではない. - B (correct): 0-size chunkが明示終端. - C (incorrect): Content-Lengthをtrailerとして使って終端する仕組みではない. **Related:** trailerは終端chunkの後に現れるheader field群.

**Explanation:** **Terms:** request-target, origin-form, absolute-form, authority-form, asterisk-form. 接続先がoriginかproxyか, CONNECTかOPTIONSかで使う形が変わる. **Correct (A,B,C,D):** 4つ全てが定義されており, それぞれ用途がある. **Options:** - A (correct): 通常のorigin向けは/path?query. - B (correct): proxy向けに完全URIを書くことがある. - C (correct): CONNECTでhost:portを指定. - D (correct): OPTIONS * でサーバ全体のoptionsを問う. **Related:** proxyはrequest-targetの取り扱いを誤ると, 意図しない宛先へ転送してしまう.

**Explanation:** **Terms:** persistent connection, Connection: close. HTTP/1.1は効率のためにTCP connectionの再利用を基本とする. **Correct (C):** デフォルトはpersistentで, どちらかがcloseを示すまで継続する. **Options:** - A (incorrect): それは非効率で, HTTP/1.0的な挙動. - B (incorrect): 再利用がコア機能. - C (correct): これが標準のデフォルト. **Related:** persistentにするにはframingが正しくなければならない. 境界が曖昧だと再利用が危険になる.

**Explanation:** **Terms:** CRLF. HTTP/1.1の行終端はCRLFとして定義される. **Correct:** CRLF. **Why others are wrong:** LF-onlyはテキストファイルでは一般的でも, HTTP/1.1の定義上の区切りではない. **Related:** 実装は寛容に受理することがあっても, 送信は正しいCRLFで出すのが相互運用性に有利.