tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cyrille Le Clerc <>
Subject Re: HTTP connector to be aware of proxied SSL requests
Date Thu, 17 Jun 2010 22:30:26 GMT
Hello Matt,

I think the RemoteIpValve does what you need : it looks at http
headers filled in the request by preceding network components (layer 7
load balancer, ssl accelerator, etc) such as 'x-forwarded-for' to get
the real ip address and 'x-forwarded-proto' to get the http/https
protocol. A concept of internal/trusted incoming proxies is used to
decide weither the http headers can be trusted or not.

Configuration is detailed in the javadocs :
The documentation of RemoteIpValve has been enhanced in Tomcat 7 to
integrate the content of the java doc.

I wrote a blog post in french to explain how it works with detailed
diagrams here :

Basically, if you want to trust http header x-forwarded-for and
x-forwarded-proto coming from LB/web-server and, the valve configuration will look like :

<Server ...>
   <Service name="Catalina">
      <Connector ... />
      <Engine ...>
         <!-- Process X-Forwarded-For to get remote address and
X-Forwarded-Proto to identify SSL requests -->
               internalProxies="192\.168\.0\.10, 192\.168\.0\.11"
               protocolHeader="X-Forwarded-Proto" />

         <!-- AccessLogValve must be declared after RemoteIpValve to
get the remote address and the scheme https/http -->
         <Valve className="org.apache.catalina.valves.AccessLogValve"
directory="logs" pattern="common" prefix="access_log."
            resolveHosts="false" suffix=".txt" />


Please note that you can simplify the configuration omitting
'internalProxies' attribute and rely on the default that trusts all
the class A, B & C private IP addresses.

Hope this helps,


Cyrille Le Clerc

On Thu, Jun 17, 2010 at 2:41 AM, Matt Peterson <> wrote:
> Hi All,
> We have a hardware load balancer terminating SSL requests before making a
> plain-text connection with Tomcat. So that all contexts are aware that the
> request is actually a secure request, we have implemented the RemoteIpValve
> with a LB injected header. This works well for our apps. However, we have
> noticed that there is some processing of the request happening within the
> connector, before the valves are processed. In particular, the redirecting
> to URLs with a trailing slash. Because this processing is occurring before
> the valves are processed the Connector still thinks that the original
> request was a non-secure one, even though it was not. The result is that
> requests to are redirected to
> instead of to This
> is not major, because our LB then redirects from
> to and all is good (except for the extra
> redirect).
> I can't find any documentation on the order of events for the Connector, so
> I'm not sure what other decisions get made based on the request attributes,
> but assume there are others.
> Is there another solution to handling proxied SSL requests so that Catalina
> as well as our apps are aware that the requests are secure??? One
> possibility is to have two Connectors (1 using the secure, scheme and
> serverPort attributes for secure and 1 for non-secure) and have the LB
> connect to the appropriate Connector depending on the request. But this
> effectively doubles the amount of config needed to be managed (2nd set of
> config for LB + 2nd connector), which is considerable when dealing with 6 TC
> clusters each with their own set of LB config.
> Should I lodge an enhancement request for the Connector to become aware of
> proxied SSL requests (perhaps via an injected x-forwarded-proto header, ala
> WebLogic)?
> Cheers,
> Matt.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message