RFC 7239 Quiz

**Explanation:** **Terms:** proxy, intermediary, metadata **Correct (A):** proxyが観測した情報を, 標準形式で伝えるためのheader **Options:** - A (correct): 目的そのもの - B (incorrect): 暗号化はTLS - C (incorrect): 信頼できるproxyの境界が前提 **Related:** どのhopがheaderを追加し, どこでstripするかを設計する

**Explanation:** **Terms:** parameter, token, quoted string **Correct (A,B,C,D):** よく使う標準parameter **Related:** 値はquoted stringになり得る

**Explanation:** **Terms:** list syntax, forwarded element **Correct (B):** 1elementが1hopを表し, elementはcommaで区切る **Options:** - A (incorrect): commaはlist構文 - B (correct): HTTPの一般的list表現 - C (incorrect): 指定形式ではない **Related:** quotingと空白も含めて堅牢にparseする

**Explanation:** **Terms:** trust boundary, spoofing **Correct (C):** clientが任意に付与できる環境では, headerは簡単に偽装される **Options:** - A (incorrect): 無関係 - B (incorrect): 無関係 - C (correct): 実務上の落とし穴 **Related:** trusted edgeでstripして, 付与し直すのが典型

**Explanation:** **問題を出した背景:** `Forwarded` は parameter 名が短いので, `for`, `by`, `host`, `proto` を混同しやすいです. client 側起点の情報をどれが表すかを確認する問題です. **用語:** **`for` parameter** は request initiator, つまり元の client に相当する情報を表します. 値は IP literal のことも, privacy を意識した obfuscated value のこともあります. **Correct:** **for**. **Why this matters:** `for` は analytics や audit log で使われがちですが, trust boundary をまたぐ metadata でもあります. どこまで保存・露出するかの方針とセットで扱う必要があります.

**Explanation:** **Terms:** privacy, data minimization **Correct (A):** Forwardedは情報量が多くなり得るため, 最小化ポリシーが重要 **Options:** - A (correct): privacyと内部情報保護 - B (incorrect): 理由ではない - C (incorrect): security featureではない **Related:** loggingとanalyticsでも, 保存方針を明確にする