RFC 9110 Quiz

**Explanation:** HTTP semanticsはprotocol version間で共通ですが, framingとtransport mechanismは変わります. API設計, proxy動作, client library, cache reviewではwire formatでなくmethodとresponseの意味を扱います. semantics(セマンティクス), transport, methodの意味. ここでのセマンティクスは, HTTP/1.1, HTTP/2, HTTP/3のどの運び方でも共通に成り立つ"意味/ルール"の話. HTTP/1.1のtext line, HTTP/2のframe, HTTP/3のQUIC streamではwire表現が異なりますが, GETのsafeやidempotentといったmethod semanticsは共通です. safe, idempotent, cacheable, status codeの意味はセマンティクスの中心です. これは transport が変わっても変わらない, HTTP そのものの意味づけです. - A (correct): methodの意味と許される副作用の話. - B (incorrect): framingはtransport mappingの話. - C (incorrect): QUICのpacket挙動はtransportの話. セマンティクスが分離されているから, プロキシやキャッシュは下位 transport と独立に判断できます. RFC 9110, 9112, 9113, 9114 を役割ごとに読むと全体像がつながります.

**Explanation:** safeは"serverが一切writeしない"という実装条件ではなく, clientが要求するactionの性質です. crawler, prefetch, link checker, cache最適化では, user確認なしに自動実行してよいmethodかを判断します. safe method. safeはdefined semanticsが本質的にread-onlyで, clientがstate changeを要求・期待しないことです. loggingなどclientが要求していない付随効果はあり得ます. GETは取得を要求するsafe methodです. implementation内部で付随効果が起き得ることとは両立します. - A (correct): GETのdefined semanticsはsafeです. - B (incorrect): POSTは一般に状態変化を伴いsafeではない. - C (incorrect): DELETEは削除でありsafeではない. safeはclientが要求するsemanticsの性質で, server内部に一切writeがないという保証ではありません. cacheableとも別概念です.

**Explanation:** idempotencyは同一responseや, 全retryが運用上無条件に安全という保証と混同されやすい概念です. idempotent method. 同じリクエストを複数回送っても, 意図する効果が1回と同じになる性質. PUTとDELETEはidempotentとして定義されます. 同じrequestを繰り返したときのintended effectが1回と同じという意味で, 各responseや付随効果まで同じとは限りません. - A (correct): PUTは置き換えなので繰り返しても収束する. - B (incorrect): POSTは通常idempotentではなく, 繰り返すと重複作成や二重処理になり得る. - C (correct): DELETEは最終的に"無い"状態へ収束する. - D (incorrect): CONNECTはトンネル確立で, 一般にidempotent扱いではない. idempotencyはretry, LB, ネットワーク障害時の復旧設計で重要.

**Explanation:** status-code classは, clientがcode固有の処理を行う前に読むresponse meaningの第一層です. client, gateway, monitoring, retry logicは, 個別codeを見る前にstatus classで大きな処理経路を選びます. status code class. 先頭の数字は仕様上の大分類を示す. 3xxはredirectionで, クライアントが追加の動作や別URIの使用を求められる. - A (incorrect): 4xxがclient error. - B (correct): 3xxがredirection. - C (incorrect): 5xxがserver error. 304 Not Modifiedも3xxで, cache validationの文脈で使われる.

**Explanation:** A: RFC 9110 Section 13.2.1は, conditionなしの同じrequestがcontent処理前に2xxまたは412以外となる場合, preconditionを無視すると定めます. B: action後の評価ではIf-Matchが守るべきstale updateを防げません. C: 独立に判定できるauthorization failureが優先され, state changeは行いません. authorization成功時はcontent処理またはmethod actionの直前にpreconditionを評価します. D: entity tagはrepresentation stateの識別子でありauthentication credentialではありません. 判定基準: unconditional requestが成功可能かを先に決め, その後method適用前にrepresentation preconditionを評価します.

**Explanation:** A: RFC 9110 Section 15.6.5の504はgatewayがtimely upstream responseを受けなかったことを示すだけで, backendがactionをしていない証明ではありません. B: Section 9.2.2はmethod semanticsでautomatic retryを区別します. response消失は既に起きたeffectを消しません. C: Section 9.2.2は, request semanticsが実質idempotentとclientが知るか, 初回未適用を検出できる場合に限りnon-idempotent methodのretryを認めます. D: POSTは普遍的に再送不能ではありません. operation ID, deduplication contract, state checkなどが必要なknowledgeを提供できますが, RFC 9110自体はそのcontractを作りません. 判定基準: retryはresponse不在やauthorization grantのvalidityではなく, operation effectについての証拠で決めます.