RFC 9110 Quiz

HTTPのセマンティクスを正しく扱う

0 / 0

References (URLs)

狙い: 適切なmethodとheaderを選び、レスポンスの意味を一貫して解釈する。

Q1: 次のうち, HTTPのtransport詳細ではなくHTTPのセマンティクス(意味/ルール)に当たる話題はどれ

Multiple Choice
RFC 9110 は, HTTP/1.1, HTTP/2, HTTP/3 の下回りではなく, それらに共通する「意味」を定義します. まず semantics と framing/transport を層で分けると読みやすくなります.
HTTP Semantics method, status code, header の意味 HTTP/1.1 text framing HTTP/2 binary frame HTTP/3 QUIC stream
**Explanation:** **Terms:** semantics(セマンティクス), transport, methodの意味. ここでのセマンティクスは, HTTP/1.1, HTTP/2, HTTP/3のどの運び方でも共通に成り立つ"意味/ルール"の話. **RFCを読むときの見方:** RFC 9110 を読むときは, 「どう運ぶか」ではなく「何を意味するか」を読んでいると意識すると迷いにくいです. 同じ GET でも, HTTP/1.1 の text line, HTTP/2 の frame, HTTP/3 の QUIC stream という違いはありますが, safe や idempotent の意味は共通です. **Correct (A):** safe, idempotent, cacheable, status codeの意味はセマンティクスの中心です. これは transport が変わっても変わらない, HTTP そのものの意味づけです. **Options:** - A (correct): methodの意味と許される副作用の話. - B (incorrect): framingはtransport mappingの話. - C (incorrect): QUICのpacket挙動はtransportの話. **Related:** セマンティクスが分離されているから, プロキシやキャッシュは下位 transport と独立に判断できます. RFC 9110, 9112, 9113, 9114 を役割ごとに読むと全体像がつながります.

Q2: safeと定義されるmethodはどれ

Multiple Choice
**Explanation:** **Terms:** safe method. safeは, origin serverの状態変化を意図しないread-only操作であること. **Correct (A):** GETはsafe. ログなどの付随効果はあり得るが, リソース状態を変える意図は持たない. **Options:** - A (correct): GETは取得でありsafe. - B (incorrect): POSTは一般に状態変化を伴いsafeではない. - C (incorrect): DELETEは削除でありsafeではない. **Related:** safeとcacheableは別概念. cache可能かはheaderなどの条件に依存する.

Q3: idempotentなmethodはどれ (複数選択)

Multi-Select
**Explanation:** **Terms:** idempotent method. 同じリクエストを複数回送っても, 意図する効果が1回と同じになる性質. **Correct (A,C):** PUTとDELETEはidempotentとして定義される. 実運用では部分失敗もあり得るが, 仕様上は再試行が想定される. **Options:** - A (correct): PUTは置き換えなので繰り返しても収束する. - B (incorrect): POSTは通常idempotentではなく, 繰り返すと重複作成や二重処理になり得る. - C (correct): DELETEは最終的に"無い"状態へ収束する. - D (incorrect): CONNECTはトンネル確立で, 一般にidempotent扱いではない. **Related:** idempotencyはretry, LB, ネットワーク障害時の復旧設計で重要.

Q4: 3xxのstatus codeが一般に示すものはどれ

Multiple Choice
**Explanation:** **Terms:** status code class. 先頭の数字は仕様上の大分類を示す. **Correct (B):** 3xxはredirectionで, クライアントが追加の動作や別URIの使用を求められる. **Options:** - A (incorrect): 4xxがclient error. - B (correct): 3xxがredirection. - C (incorrect): 5xxがserver error. **Related:** 304 Not Modifiedも3xxで, cache validationの文脈で使われる.

Q5: Cache-Control: no-store の意味として最も正しいのはどれ

Multiple Choice
**Explanation:** **Terms:** cache, store, revalidate. Cache-Controlは保存や再利用条件を制御する. **Correct (C):** no-storeは強い指示で, 保存しないことを求める. **Options:** - A (incorrect): これはno-cacheに近い. no-cacheは保存はできるが再利用時に検証が必要. - B (incorrect): no-storeは原則として広く適用される. shared cache限定ならprivateなど別の指示が関係. - C (correct): 応答を保持しない. **Related:** 秘匿性の高いデータにはno-storeを使い, ブラウザcacheやプロキシに残らないようにする.

Q6: representationのmedia typeを示すheader fieldはどれ

Short Text
**Explanation:** **Terms:** representation, media type. media typeはpayloadの解釈方法を受信側に伝える. **Correct:** Content-Type. **Why others are wrong:** Content-Lengthはサイズ, Acceptは希望, Hostはauthority. payloadの型を宣言しない. **Related:** charsetなどのparameterはデコードや安全性に影響する.