Bug 63943 - Add possibility to overwrite remote port with information from header value
Summary: Add possibility to overwrite remote port with information from header value
Alias: None
Product: Tomcat 9
Classification: Unclassified
Component: Catalina (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement (vote)
Target Milestone: -----
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2019-11-20 11:03 UTC by Peter Gierl
Modified: 2020-11-27 12:33 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Peter Gierl 2019-11-20 11:03:32 UTC
In times of IPv6 networks being mapped into IPv4 networks it is often necessary to have the remote port information to identify the source of a request.

Please enhance the org.apache.catalina.valves.RemoteIpValve to allow using port information from a request header set by a load-balancer or proxy.

Alternatively provide a separate valve for this functionality.
Comment 1 Mark Thomas 2019-11-20 11:50:22 UTC
This feature has been present since May 2011.
Comment 2 Peter Gierl 2019-11-20 14:23:40 UTC
It's not implemented in RemoteIpValve, only the server port information may be transported, not the remote port. So where is it present?
Comment 3 Mark Thomas 2019-11-20 15:45:16 UTC
Sorry, now I understand. You want to be able to set the value returned from ServletRequest.getRemotePort() based on a header.

Is there a standard, OK typical, name for this header (we can make it configurable anyway).

Note there is also bug 63080.
Comment 4 George Stanchev 2019-11-21 01:09:19 UTC
According to [1] it is "x-forwarded-port"

Comment 5 Mark Thomas 2019-11-21 08:22:33 UTC
(In reply to George Stanchev from comment #4)
> According to [1] it is "x-forwarded-port"

No, that is the port on the proxy that the client connected to (already supported). The enhancement request is for the port that the client connected from.
Comment 6 Nicolò Boschi 2020-04-15 16:12:07 UTC
Why can't you just read the header value?
Comment 7 Mark Thomas 2020-04-15 16:38:36 UTC
Because users want to write applications that "just work" irrespective of whether there is a reverse proxy in front of Tomcat and/or how that reverse proxy is configured.
Comment 8 Mark Thomas 2020-11-27 12:33:17 UTC
A little research suggests that this is usually included in the X-Forwarded-For header rather than as a separate header. RFC 7239 uses that format as does Azure. I haven't found any references to a dedicated header.

Any reason to to address this by adding support for port as well as address in X-Forwarded-For ?