ToppyMicroServices

RFC 7239 Quiz

Forwarded header

πŸ‡ΊπŸ‡Έ πŸ‡―πŸ‡΅
0 / 0

References (URLs)

Scope: RFC 7239 defines optional request metadata that proxies may add, preserve, or remove. It defines syntax and disclosure semantics, not proof that a client, proxy, agent, or authorization claim is authentic.

Q1: May the backend use the first for value as an authenticated client address?

Multiple Choice

An Internet client sends Forwarded: for=10.0.0.7. A trusted edge proxy appends for=198.51.100.24 without removing the incoming field, and the backend authorizes administrators when the first for value is in a private range.

**Explanation:** A: List order records generation order; it does not authenticate an element. B: A client can send arbitrary HTTP field values, including private-looking addresses. C: RFC 7239 Section 8.1 says the field cannot be relied upon to be correct because every node can modify it. A deployment may sanitize untrusted fields and trust observations from a defined edge, but RFC 7239 alone does not make even those values authorization evidence. D: Section 4 permits a proxy to append a new element or add a new field line; the defect is retaining an attacker-controlled prefix and trusting it.

Q2: Which logical list must the origin parse?

Multiple Choice

The origin receives two field lines in this order: Forwarded: for=192.0.2.43 and Forwarded: for="[2001:db8:cafe::17]";proto=https.

**Explanation:** A: Semicolons separate parameters within one forwarded-element; a parameter cannot occur twice in that element. B: RFC 7239 Sections 4 and 7.1 define an HTTP list that may be split over multiple field lines. The first element is the first proxy's contribution, followed by later contributions. C: The list is not reversed merely because the last proxy is closest to the origin. D: Multiple field lines are allowed and are equivalent to the combined comma-separated representation.

Q3: May this proxy emit the proposed element?

Multiple Choice

A proxy wants to record both the socket peer and an application-supplied address as Forwarded: for=192.0.2.10;for=198.51.100.8;proto=https.

**Explanation:** A: RFC 7239 defines no trust ranking for duplicate parameters. B: A comma starts another forwarded-element; a semicolon adds another parameter to the same element. C: The value type does not create an exception for duplicates. D: Section 4 says each parameter MUST NOT occur more than once per field-value/forwarded-element. Distinct proxy contributions require distinct comma-delimited elements.

Q4: Can the proxy safely translate these legacy fields into paired elements?

Multiple Choice

A request arrives with both X-Forwarded-For and X-Forwarded-By lists. Their producers and insertion order are not known, but the proxy proposes pairing values by array index and converting them to Forwarded.

**Explanation:** A: Matching lengths do not establish that independently generated entries correspond. B: Lexical order has no relationship to traversal order. C: RFC 7239 Section 7.4 warns that conversion may be impossible when multiple X-Forwarded-* fields exist because the order in which existing fields were added is unknown. D: The RFC encourages sensible conversion when information is sufficient; for example, a lone X-Forwarded-For list can often be translated.

Q5: Which forwarding policy best follows RFC 7239's privacy guidance?

Multiple Choice

A proxy receives a request carrying fields that specifically request privacy semantics. Operations would prefer to forward the client's stable IP address for debugging, but no address-based backend function requires it.

**Explanation:** A: Section 8.3 gives privacy-sensitive requests priority: the proxy SHOULD NOT use Forwarded or otherwise pass private information to the next hop. B: This follows the stated privacy guidance. Where the field is used without that signal, Sections 5.1, 5.2, and 8.3 recommend obfuscated identifiers by default. C: Section 8.2 says the field should never be copied into responses because that can expose the proxy chain. D: Obfuscated identifiers should be random per request unless persistence is needed, and persistent identifiers should not outlive client IP addresses.

Q6: How should an A2A backend use the forwarded metadata?

Multiple Choice

A trusted gateway receives an external A2A request, replaces all incoming Forwarded fields, and sends Forwarded: for=198.51.100.24;proto=https;host=agent.example to a backend over authenticated transport. The backend proposes treating the value as proof of the agent runtime, grant holder, approved task, and delegation chain.

**Explanation:** A: Sanitization and authenticated gateway-to-backend transport can make the gateway's observation trustworthy within that boundary, but do not give the field new application semantics. B: RFC 7239 does not prove either agent identity or grant possession. C: Sections 4, 5, and 8.1 define forwarding metadata and its integrity limitations. An A2A profile, credential validation, sender-constraining mechanism, task policy, and delegation rules must establish the independent application claims. D: Section 4 explicitly applies the request field to forwarding and reverse proxies; it prohibits use in responses, not reverse-proxy requests.