RFC 9112 Quiz

**Explanation:** header section, empty line, CRLF. HTTP/1.1では, headerの終端とbodyの開始は空行で区切られる. header sectionの終端が曖昧だと, 同じbyte列をproxyとoriginが異なるmessageとして解釈し, request smugglingにつながり得ます. 最後のheader fieldの後に, CRLFだけの空行が来ることでheader sectionが終了します. ここを基準に body の開始位置が決まるので, line ending の扱いは単なる書式ではなく framing そのものです. - A (incorrect): Content-Lengthはbodyの長さのヒントで, header sectionの終端ではない. - B (incorrect): そのCRLFは1本のfield lineを終えるだけです. sectionの終端には空行を表すもう1つのCRLFが必要です. - C (correct): 空行が区切りになる. 終端解釈のズレはrequest smugglingの原因になり得ます. だから RFC 9112 は, 些細に見える改行規則をかなり丁寧に定義しています.

**Explanation:** close-delimited responseとは, 宣言した長さやchunked terminatorではなく, serverのconnection closeでbody末尾を示すresponseです. この200 responseは先行するbody-length規則のどれにも該当しないため, serverがconnectionを閉じる前に受信した全octetがbody長になります. - A (incorrect): 他のframing規則が該当しないときにbody長0となるのはrequestであり, この200 responseではありません. - B (incorrect): CRLFはbody content中にも現れ得るため, close-delimited responseの区切りにはなりません. - C (correct): connection closeがdelimiterとなるので, それより前のbody octetをすべて数えます. close-delimited responseでは正常完了とnetwork interruptionを区別できないため, RFC 9112は可能なら明示的なlengthまたはtransfer codingを使うよう勧めています.

**Explanation:** chunked coding, terminator. chunked transfer codingはchunkの連続でbodyを表現する. サイズ0のlast chunkでcontent chunkの終了を示し, optional trailer sectionの後に最後の空行でchunked codingを終えます. - A (incorrect): closeはchunkedの通常の終端ではない. - B (correct): サイズ0のchunkがcontent chunkの終了を示し, trailer fieldと最後の空行がcoding全体を完結させます. - C (incorrect): Content-Lengthをtrailerとして使って終端する仕組みではない. trailer fieldはサイズ0のlast chunkの後, 最後の空行の前に現れます.

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

**Explanation:** A: close-delimited responseはconnection終了でだけ終わるため, closed connectionに後続responseをframingできません. B: RFC 9112 Section 6.3はbodyをserver closure前の全octetと定めます. Section 9.3はpersistenceにvalid Content-Lengthや適用可能なfinal chunked codingなどself-defined lengthを要求します. C: 任意response body内のCRLFはdataであり, 次messageの信頼できるboundaryではありません. D: framingとconnection optionが許せばpersistent connectionがHTTP/1.1のdefaultです. 判定基準: persistenceだけでは不十分で, reusable connection上の各messageはconnection closureから独立したlengthを必要とします.

**Explanation:** A: hop間で異なるframing decisionをすること自体がrequest smuggling条件であり, extensibilityではありません. B: RFC 9112 Section 6.3はTransfer-Encodingを優先します. 矛盾するContent-Lengthへ置換するとmessage boundaryが変わり得ます. C: Section 6.3は組合せがrequest smugglingを示し得るためerror扱いが望ましいとします. 転送を選ぶintermediaryはContent-Lengthを削除し, 先にTransfer-Encodingを処理しなければなりません. D: parsing後の一致確認では両field転送は安全になりません. downstreamが比較前に別boundaryを選ぶ可能性があります. 判定基準: forward前にreceiving hopで1つのcanonical message boundaryを確立し, 競合するlength signalをtrust boundary越しに残しません.