net/http/httputil: Reverse Proxy X-Forwarded-For include Port

[WesleyJeanette]

In the reverse proxy the port is not being added to the header X-Forwarded-For. The port is not a requirement but optional. From RFC 7329

If the server receiving proxied requests requires some
   address-based functionality, this parameter MAY instead contain an IP
   address (and, potentially, a port number).

As the port currently isn't being included by default, and it is something I need, I am explicitly setting the header. The result is I end up with X-Forwarded-For: 123.34.567.89:9876, 123.34.567.89. It would be great to either add an option to include the ports or do a check that the value about to be added doesn't already exist in the string (duplicate without the port).

go/src/net/http/httputil/reverseproxy.go

Lines 249 to 257 in 3089d18

	if clientIP, _, err := net.SplitHostPort(req.RemoteAddr); err == nil {
	// If we aren't the first proxy retain prior
	// X-Forwarded-For information as a comma+space
	// separated list and fold multiple headers into one.
	if prior, ok := outreq.Header["X-Forwarded-For"]; ok {
	clientIP = strings.Join(prior, ", ") + ", " + clientIP
	}
	outreq.Header.Set("X-Forwarded-For", clientIP)
	}

[bradfitz]

Sure, we could add a bool on ReverseProxy for including the port. Or maybe make it an new enum type where zero value means current behavior but let people turn it off, on explicitly (despite it being the default), or on with port.

But the behavior you mention of dup-suppressing by matching on the IP with any port is also fine to do by default without knobs. Or maybe it wouldn't matter with the previous knob, actually.

[solodynamo]

Acc to https://golang.org/pkg/net/http/#Request, server sets `RemoteAddr` to an "IP:port" so It should have been concatenated with the prior `X-Forwarded-For` in above snippet.

[AndrewBurian]

The functionality to include a port number is specified in RFC 7329, which defines the Forwarded header, not the non-standard X-Forwarded-For header.

I still stand by that a better option is to support the Forwarded header and add the port to it rather than debate the merits and update implementation for a header that has no rules.

[luka-zitnik]

How does the support for Forwarded header relate to backward compatibility?

I think backward compatibility is missing in the linked patch. The X-Forwarded-For is still a de-facto standard.

After the backward compatibility is in place, even this issue could be easily solved, e.g. a boolean to forward client port could apply to either of the header fields.

ps I'm looking for a way to make first contribution.