On 09/05/2011 13:48, Konstantin Kolinko wrote: > 2011/5/9 <ma...@apache.org>: >> Author: markt >> Date: Mon May 9 10:09:44 2011 >> New Revision: 1100940 >> >> URL: http://svn.apache.org/viewvc?rev=1100940&view=rev >> Log: >> Add additional configuration options to the RemoteIpValve to control ports. >> These are required by my TCK test environment since I have multiple >> connectors (with different ports) configured all using the one Valve. >> If this has the desired effect, I'll port the changes to the RemoteIpFilter. >> >> Modified: >> tomcat/trunk/java/org/apache/catalina/valves/LocalStrings.properties >> tomcat/trunk/java/org/apache/catalina/valves/RemoteIpValve.java >> tomcat/trunk/webapps/docs/changelog.xml >> tomcat/trunk/webapps/docs/config/valve.xml >> > >> --- tomcat/trunk/java/org/apache/catalina/valves/LocalStrings.properties >> (original) >> +++ tomcat/trunk/java/org/apache/catalina/valves/LocalStrings.properties Mon >> May 9 10:09:44 2011 >> @@ -40,6 +40,7 @@ errorReportValve.rootCauseInLogs=The ful >> >> # Remote IP valve >> remoteIpValve.syntax=Invalid regular expressions [{0}] provided. >> +remoteIpValve.invalidPortHeader=Invalid value [{0}] found for port in HTP >> header [{1}] > > s/HTP/HTTP/
Thanks. Fixed. >> + } catch (NumberFormatException nfe) { >> + log.debug(sm.getString( >> + "remoteIpValve.invalidPortHeader", >> + portHeaderValue, portHeader), nfe); >> + } > > if (log.isDebugEnabled()){...} Also fixed. >> + used by the client to connect to the proxy. If not specified, the >> + default of <code>null</code> is used.</p> > > Maybe treat an empty string as if it were he null. We don't do that elsewhere in this code. > Is all this intended for HTTP/1.0 or 0.9 requests? > (HTTP/1.1 ones should have Host: header) It is intended for when Tomcat is behind a reverse proxy and the application expects getLocalPort() and getServerPort() to return the port numbers the client is using. (Yes, I know that isn't what getLocalPort() is meant to do.) My specific use case was: - single Tomcat instance with single http connector - single httpd instance listening on multiple ports - port-based virtual hosts on httpd - each virtual host reverse-proxied to Tomcat using mod_proxy_http Tomcat needed to know which port the request came in on. The problem is that the RemoteIpValve assumes a single port for http and https rather than obtaining them from the host header. An alternative approach would have been to get the port from the host header but this gives maximum flexibility. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org