Forwarded HTTP Extension
draft-ietf-appsawg-http-forwarded-10

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>
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/

Ballot Text

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.

RFC Editor Note