It looks like it. That seems to indicate its content is generally stable and already discussed but is considered immature still due to lack of implementations. It might be worth checking how it compares overall to our existing support in UriComponentsBuilder#fromHttpRequest. Considering the nature of the spec there probably isn't too much risk of change and it would be just a matter of adapting to the header names and syntax.
I am not convinced they are. Those parameters take the IP address of the client, so it would be logical if the port number is the client-side port; not the server-side port. Otherwise, you would have a client-side IP address with a server-side port, and that doesn't make a lot of sense to me.
Let's take a look at an example, adapted from the RFC: a request from a client with IP address 192.0.2.43 passes through a proxy with IP address 198.51.100.17, before reaching an origin server. The client-side port is 1234, the proxy server-side port is 80, the proxy client-side port is 5678, and the server server-side port is 8080. In other words, we the following connections:
In my understanding, the RFC states the following:
The HTTP request between the client and the proxy has no "Forwarded" header field.
The HTTP request between the proxy and server has a "Forwarded: for=192.0.2.43:1234" header field. Or should the header be "Forwarded: for=192.0.2.43:80”? But that would be quite strange, since it would combine a client-side IP with a server-side port.
I am going to ask for feedback to the RFC authors on this, because this is confusing. At any rate, it looks this won't be in 4.2. RC1.
According to the RFC authors, the second request should have a "Forwarded: for=192.0.2.43:1234" header field, which suggest that the port given in the "for" section is not a direct replacement for X-Forwarded-Port.
I've asked the subsequent question to the authors: "In RFC 7239, what is the replacement for the non-standard X-Forwarded-Port header, which in the example above should be 80? Section 7.4 of the RFC, covering the transition from these “old” headers, does not cover it. Or is there no replacement for this header?"
There is no defined replacement for this header. Adding it would require a new RFC that has been IESG or WG sponsored documents. It was made this complicated as there were significant concerns about these headers from a security and privacy point of view.