tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Peterson" <matt.peter...@une.edu.au>
Subject HTTP connector to be aware of proxied SSL requests
Date Thu, 17 Jun 2010 00:41:10 GMT
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 https://domain.name/context are redirected to
http://domain.name/context/ instead of to https://domain.name/context/. This
is not major, because our LB then redirects from http://domain.name/context/
to https://domain.name/context/ 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.


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message