Skip to main content

Forwarded HTTP Extension
RFC 7239


No Objection

(Brian Haberman)
(Gonzalo Camarillo)
(Ralph Droms)
(Russ Housley)


(Sean Turner)
(Wesley Eddy)

Note: This ballot was opened for revision 07 and is now closed.

Barry Leiba Former IESG member
Yes (2012-08-30 for -07) Unknown
There have been questions about whether anyone really discussed the value of standardizing this, as opposed to just jumping in and working out the details.  Here's a brief citation of some of the related discussion on the httpbis mailing list from April 2011, when Andreas started the discussion of the predecessor document,

Karl Dubost:
Are there other products/companies using X-Forwarded-For?
What are the products emitting the header?
What are the products parsing the header? (libraries, etc)
What are the usual mistakes, errors, etc we might have to face when parsing this header?

Matt Domsch:
> Are there other products/companies using X-Forwarded-For?
> What are the products emitting the header?

Apache mod_proxy emits the header, at least when used as a reverse proxy (front end for web applications).

Willy Tarreau:
I know quite a number of companies using it for logging purposes.

> What are the products emitting the header?

At least apache , haproxy and squid immediately come to mind.
Haproxy already emits it for IPv4 and IPv6 addresses and uses
no brackets, it emits it as returned by inet_ntop().

> What are the products parsing the header? (libraries, etc)

haproxy is able to use it for various purposes (IP-based ACL
filtering, transparent binding, etc...). Right now it only
parses it for IPv4 addresses, so adding support for both
brackets and non-brackets forms is not a problem.

Martin Thompson:
Some form of standardization of this would be useful for us.  We plan to use this for more than just logging.  Of course, we'll cope without a formal definition. 

I'll note that adding a new header is nice, but it actually means more work - we still have to process X-Forwarded-For to support all the existing stuff.  Is the "X-" so offensive?  Is there a reason not to simply specify what everyone does.

Mark Nottingham:
It's not so much that; it's that there's no interop on the contents of X-Forwarded-For for IPv6 headers (AFAIK), so we should take the opportunity to define a new header that specifies it well.

While we're at it, I'd like to see extensibility points added; there are a bunch of bits of per-hop metadata that would be nice to allow in here, instead of defining separate headers. For example, in some use cases it'd be good to identify the receiving address, as well as the sending one.

Brian Pane:
> There is no current uses of "Forwarded-For", backwards compatibility
> therefore does not prevent us from doing it right.

I look at it a bit differently: there are many current uses of
Forwarded-For.  Every web proxy I've seen in the past decade uses it,
every web server has an option to log it, and every nontrivial web
analytics system parses it.  They all do expect the "X-" in front,
though.  The rollout of a naming change will be difficult; I
anticipate that proxy servers will end up sending both X-Forwarded-For
and Forwarded-For for many years.  That might be inevitable, but it
brings to mind two concerns:
- People who plan to log Forwarded-For data for forensic purposes will
need to keep logging X-Forwarded-For as well.
- X-F-F values can get somewhat large, and sending the value twice
(once as X-F-F and once as F-F) will help push more requests past 1MSS
in size, resulting in an extra round-trip delay in cases where the
proxy does not already have an established connection to the

I don't think either of those points is a show-stopper for
Forwarded-For, but they're nontrivial implementation challenges.

Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2012-10-09 for -09) Unknown
It took a while, but I believe we got to some good compromisetext that helps explain the purpose of your work. Thanks for the time taken to get the polish right.
Benoît Claise Former IESG member
No Objection
No Objection (2012-09-06 for -08) Unknown
I read the latest version draft-ietf-appsawg-http-forwarded-08
I believe that the authors introduced the justifications (even if this could always be improved).
While I understand the privacy issues, since X-forwarded is deployed and the WG wants to standardize this, I support the format specifications of this draft.
Brian Haberman Former IESG member
No Objection
No Objection (for -07) Unknown

Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -08) Unknown

Martin Stiemerling Former IESG member
No Objection
No Objection (2012-08-15 for -07) Unknown
I have no objection to publish the draft, but one question/suggestion:
The forwarded header is defined in such a way that it can only carry complete IP addresses, but not IP prefixes. 

Extending the header to carry IP prefixes would allow to make a tradeoff between user privacy and interest of the other end in learning about from where the request came.
Such a prefix could, for instance, say instead of giving the full IP address of

Would this make sense?

OTOH browser finger printing can potentially anyhow allow to figure who what user is doing the request.
Pete Resnick Former IESG member
No Objection
No Objection (2012-08-28 for -07) Unknown
Section 4:

   A proxy server that wants to add a new "Forwarded" header field value
   can either append it to the last existing "Forwarded" header field
   after a comma separator or add a new field at the end of the header
So, let's say that I have:

Forwarded: FOO
Via: BAR

that appear in that order. Is it still OK for me to append if I am not on the lookout for Via?

Forwarded: FOO,BAZ
Via: BAR

Will that screw things up semantically because now I don't know which order the events happened in?

If that's not a problem, it seems to me that:

Forwarded: FOO
Forwarded: BAR

is semantically equivalent to:

Forwarded: FOO, BAR

If that is true, I think you should explicitly say that at the end of section 4. Would I be allowed to collect together multiple Forwarded fields and make them one big Forwarded field?

Section 5: I find the first sentence in each of sections 5.1 and 5.2 very confusing.

5.1: "The 'by' parameter is used to disclose the interface where the request came in to the proxy server." If I understand this correctly, you are saying "The 'by' parameter identifies the interface on the proxy server creating the Forwarded information on which the request came in." If that's right, it's not clear from sentence.

5.2 "The 'for' parameter is used to disclose information about the client that initiated the request and following proxies in a chain of proxies." I think I get the first part of the sentence: "The 'for' parameter identifies the client that connected to the proxy server creating the Forwarded information." I can't figure out what the second part of the sentence means.
Ralph Droms Former IESG member
No Objection
No Objection (for -07) Unknown

Robert Sparks Former IESG member
No Objection
No Objection (2012-08-29 for -07) Unknown
The long threads on apps-discuss and ietf-general focused early on syntax details and privacy implications. Perhaps there were in-meeting conversations that discussed why standardizing this would help that weren't captured on list? It would be good to capture in this document a clear statement of why the IETF believes this is a good behavior to standardize (and be sure we have consensus behind it). This would fall out from the resolution of Adrian's discuss, which I support.
Russ Housley Former IESG member
No Objection
No Objection (for -07) Unknown

Stewart Bryant Former IESG member
(was Discuss) No Objection
No Objection (2012-10-11) Unknown
Thank you for the work that you have done to address my concerns.
Ron Bonica Former IESG member
(was No Objection) Abstain
Abstain (2012-08-29 for -07) Unknown
Supporting Stephen Farrell's position
Sean Turner Former IESG member
(was Discuss) Abstain
Abstain (for -08) Unknown

Stephen Farrell Former IESG member
(was Discuss) Abstain
Abstain (2012-08-30 for -07) Unknown
I commented on the privacy aspects of this during IETF LC and while
the resulting text (in 8.3) is such that I can accept the outcome of
that discussion is as good as we can get, I still have to say this
isn't really something that I think we would have developed
from-scratch in a WG. With this document, we're standardising
something that is the opposite of privacy-friendly, basically just
because the existing X-Forwarded-* header fields exist and are used
already and anything we developed that was more privacy-friendly
wouldn't get deployed. 

I'm also not at all clear as to who benefits from standardising
this, e.g. see my comments on 7.2 & 8.1 below. That may have been
discussed on the apps-discuss list, but I don't recall that so am
concerned that we may just be standardising this because someone had
the energy to write and process the document.

I think the document would be better if it didn't present this as
being a good (or unconditionally "needed") thing, at least without
caveats. For example, I don't think this is "needed" by users, but
rather more by others. That's mostly a writing-style thing though.

What is a "trusted path" of proxies, or a "trusted proxy"? I think
that phrase could just be deleted since there are very few cases
where anyone knows of and (equally) trusts all the proxies on a
path. I don't think the document defines that well enough for the
phrase to be kept.

Encouraging addition and modification of header fields like this
means that any future HTTP e2e integrity mechanisms will have to be
more complex than otherwise, basically about as complex as DKIM (or
the DOSETA proposal derived from that). I'm not sure if that might
or might not have a bad effect on future work with HTTP. I don't
know if that was discussed on the httpbis list or on apps-discuss.

Section 4 says proxies MUST ensure the "correct" header field is
updated but doesn't seem to say exactly how to know which header
field is the correct one.

5.4 seems to be standardising a practice that amounts to trying to
fool the user-agent into believing that TLS was used end to end when
in fact it was not. While this is so widely deployed that its
probably pointless to try even discourage, I'm not convinced that a
WG would design a standard for a server-side crypto accellerator in
this way. I think we'd be more likely to make the middlebox at least
visible to the user-agent.

7.2 doesn't seem to me to specify when to preserve the header field
and when not to do so. I don't think "direct consequence" is
something that all implementers will understand in the same way.
(If doing whatever you like is fine here, then that calls into
question the basis for standardising this in the first place.)

8.1 says this cannot be relied upon. If that's the case then why is
it being standardised? Whitelisting proxies is (as the document
admits) not a credible mitigation.

8.2 says telling the client about the proxy chain is somehow a bad
thing but doesn't justify that. Since a client could find out anyway
if they wanted to bother, that seems wrong. 

8.2 says to disallow the TRACE request. Is that a change to HTTP?
If so, then where was that discussed?

Section 9 says only that the expert should ensure that the
specification "address the security and privacy implications of the
requested parameter." So if I defined a parameter that passed on the
precise location of the end-user or the most recent healthcare
related URL they've accessed then would that be ok? I think
additional instructions are needed as to the acceptable purposes to
which such parameters can be put or else perhaps IETF review would
in fact be better. Given the field of applicability I would not be
surprised if very privacy-invasive parameters were defined in

The W3C have standardised the DoNotTrack header field. It
should be clear whether or not, and if so, how, this header 
field interacts with that one.

5.1 says "some other kind of identifier" which seems quite loose.

5.5 says widely deployed extensions SHOULD be standardized which is
an odd use of 2119.

What does "in a sensible way" mean in 7.4? That seems underspecified.
Wesley Eddy Former IESG member
Abstain (for -07) Unknown