ToppyMicroServices

RFC 7239 Quiz

Forwarded header

🇺🇸 🇯🇵
0 / 0

References (URLs)

範囲: RFC 7239は, proxyが追加・保持・削除できる任意のrequest metadataを定義します. client, proxy, agent, authorization claimが真正であることを証明する仕様ではありません.

Q1: backendは最初のfor値を認証済みclient addressとして使える?

Multiple Choice

Internet clientがForwarded: for=10.0.0.7を送ります. trusted edge proxyはincoming fieldを削除せずfor=198.51.100.24を追加し, backendは最初のfor値がprivate rangeならadministratorとしてauthorizeします.

**解説:** A: list順は生成順を記録しますが, elementを認証しません. B: clientはprivate addressらしい値を含む任意のHTTP field valueを送れます. C: RFC 7239 Section 8.1は, すべてのnodeが変更できるためfieldの正しさに依存できないとします. deploymentはuntrusted fieldをsanitizeし, 定義したedgeの観測値を信頼できますが, RFC 7239だけではその値もauthorization evidenceになりません. D: Section 4はproxyによるelement追加または新しいfield lineの追加を認めます. 問題はattacker-controlled prefixを保持して信頼することです.

Q2: originがparseすべきlogical listはどれ?

Multiple Choice

originは次の順で2つのfield lineを受け取ります: Forwarded: for=192.0.2.43, Forwarded: for="[2001:db8:cafe::17]";proto=https.

**解説:** A: semicolonは1つのforwarded-element内のparameterを区切り, そのelementで同じparameterは重複できません. B: RFC 7239 Sections 4と7.1は, 複数field lineへ分割できるHTTP listを定義します. 先頭elementは最初のproxyの寄与で, 後続の寄与が続きます. C: 最後のproxyがoriginに最も近くてもlistを逆転しません. D: 複数field lineは許され, 結合したcomma-separated representationと等価です.

Q3: proxyはこのelementを出力してよい?

Multiple Choice

proxyはsocket peerとapplication指定addressの両方をForwarded: for=192.0.2.10;for=198.51.100.8;proto=httpsとして記録しようとしています.

**解説:** A: RFC 7239はduplicate parameterのtrust rankingを定義しません. B: commaが別のforwarded-elementを開始し, semicolonは同じelementへparameterを追加します. C: value typeによって重複を許す例外はありません. D: Section 4は各parameterが1 field-value/forwarded-element内に2回以上現れてはならないとします. 異なるproxyの寄与はcommaで区切った別elementにします.

Q4: legacy fieldを安全にpaired elementへ変換できる?

Multiple Choice

requestにX-Forwarded-ForとX-Forwarded-Byの両listがあります. producerと挿入順序は不明ですが, proxyはarray indexで値をpairingしてForwardedへ変換する案です.

**解説:** A: 長さの一致は, 独立に生成されたentryの対応を確立しません. B: lexical orderはtraversal orderと無関係です. C: RFC 7239 Section 7.4は, 複数のX-Forwarded-* fieldがある場合, 既存fieldの追加順序が不明なため変換不能になり得ると警告します. D: 情報が十分なら合理的な変換を推奨します. 例えばX-Forwarded-Forだけのlistは変換できる場合があります.

Q5: RFC 7239のprivacy guidanceに最も合うforwarding policyはどれ?

Multiple Choice

proxyはprivacy semanticsを明示的に要求するfieldを持つrequestを受け取ります. 運用担当はdebug用にclientのstable IP addressを転送したい一方, backendのaddress-based機能は必要としていません.

**解説:** A: Section 8.3はprivacy-sensitive requestを優先し, proxyはForwardedを使わずprivate informationも次hopへ渡さないSHOULD NOTを示します. B: これは記載されたprivacy guidanceに従います. そのsignalなしでfieldを使う場合, Sections 5.1, 5.2, 8.3はdefaultとしてobfuscated identifierを推奨します. C: Section 8.2はproxy chainを露出し得るためfieldをresponseへcopyすべきでないとします. D: obfuscated identifierはpersistenceが必要でない限りrequestごとにrandomとし, persistentでもclient IP addressより長く保持すべきではありません.

Q6: A2A backendはforwarding metadataをどう使うべき?

Multiple Choice

trusted gatewayが外部A2A requestを受け, incoming Forwardedをすべて置換し, authenticated transportでForwarded: for=198.51.100.24;proto=https;host=agent.exampleをbackendへ送ります. backendはこの値をagent runtime, grant holder, approved task, delegation chainの証拠として扱う案です.

**解説:** A: sanitizationとauthenticatedなgateway-to-backend transportによりgatewayの観測をboundary内で信頼できても, fieldに新しいapplication semanticsは加わりません. B: RFC 7239はagent identityもgrant possessionも証明しません. C: Sections 4, 5, 8.1はforwarding metadataとintegrity上の限界を定義します. 独立したapplication claimはA2A profile, credential validation, sender-constraining, task policy, delegation ruleで確立する必要があります. D: Section 4はrequest fieldをforwarding proxyとreverse proxyの両方へ適用します. 禁止するのはresponseでの利用です.