Forwarded HTTP Extension
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: RFC Editor <email@example.com> Subject: Protocol Action: 'Forwarded HTTP Extension' to Proposed Standard (draft-ietf-appsawg-http-forwarded-10.txt) The IESG has approved the following document: - 'Forwarded HTTP Extension' (draft-ietf-appsawg-http-forwarded-10.txt) as Proposed Standard This document is the product of the Applications Area Working Group. The IESG contact persons are Barry Leiba and Pete Resnick. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-appsawg-http-forwarded/
Technical Summary This document standardizes an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, such as the originating IP address of a request and the IP address of the proxy on the user-agent-facing interface. Given a trusted path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document is meant to replace several ad-hoc solutions already deployed today. Working Group Summary Nothing worth noting. Document Quality There are several implementations of similar header fields already in use. Personnel Alexey Melnikov is the document shepherd. Barry Leiba is the responsible AD. RFC Editor Note: 1. In the ABNF in Section 4, there are two items that have angle-bracketed text in them: token = <Defined in [I-D.ietf-httpbis-p1-messaging], Section 3.2.4> quoted-string = <Defined in [I-D.ietf-httpbis-p1-messaging], Section 3.2.4> The line breaks are artifacts of the editing and the length of the reference text. It's important that in the final version, there be no line break between the "<" and the ">". For example: token = <Defined in [RFC9999], Section 3.2.4> 2. Please make the following change in Section 8.3, paragraph 1: OLD A proxy that intends or is widely used to anonymize the user MUST NOT use the header field described in this document. NEW A proxy that intends to or is widely used to anonymize the user MUST NOT use the header field described in this document. For any proxy, if the HTTP request contains header fields that specifically request privacy semantics, the proxy SHOULD NOT use the header field described in this document.