tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Proxy Apache https to Tomcat http
Date Thu, 27 Oct 2016 17:32:00 GMT
Hash: SHA256


(I apologize, I didn't see your message from he 5th until just now. I
would have replied earlier.)

On 10/27/16 12:21 PM, Ted Spradley wrote:
On Wed, Oct 5, 2016 at 7:52 PM, Christopher Schultz wrote:
>> Explicit descriptor XML file placed in
>> CATALINA_HOME/conf/[service]/[ host]/[app].xml?
> Yes - with a caveat. The path is CATALINA_HOME/conf/[service]/[ 
> host]/context.xml

Do you mean a /literal/ context.xml? That will deploy your application
to /context.

> The only contents being one empty <Context> element with the
> docBase attribute defined
> <Context docBase="CATALINA_HOME/exampledotcomapps">
> </Context>

That's just fine.

> The CATALINA_HOME/exampledotcomapps directory contains three
> applications deployed using the manager application. 1.
> "" 2. "" 
> 3. ""

Okay, so you have a <Host> with appBase set to

Note that you aren't using the manager, here. The manager is a web
application that lets you upload and manage running applications via
an HTTP interface. Putting files on the disk under CATALINA_HOME/conf
will generally just go ahead and deploy them under a default
configuration -- that is, one where autoDeploy is set to true.

> All three applications are reached as expected through the proxy on
> port 80.
> The path CATALINA_HOME/exampledotcomapps matches the appBase
> attribute in the <Host> element for in 
> CATALINA_HOME/conf/server.xml


> I've since defined a separate Connector to listen for the redirect
>  from Apache on port 8082 because I thought there was a
> possibility the proxyPort directive would need to be specifically
> port 443 instead of port 80.

Several things: mod_proxy isn't redirecting anything... it's proxying
the connection. It sounds pedantic but it's important to use the right
terminology here since both proxying and redirects are valid ways to
change where the data is coming from. A redirect would involve the
client making a follow-up HTTP request. mod_proxy is instead handling
the client's connection on behalf of the client through to Tomcat.

The "redirect port" is the port that will be used to redirect the user
if a security-constraint cannot be fulfilled using the current
connector. Most practically, it means that if the application says "I
need TLS" and the connection isn't a TLS connection, then Tomcat will
redirect the user to the same URL but with an https:// protocol and
that port number you specify. It comes preconfigured as 8443 since
that will generally get you back to Tomcat instead of some other
service. For a real service, you probably want that set to "443".

This is the port number that the CLIENT will end up using. Using port
80 for the redirectPort will basically never work. You should leave it
as 443 if you want httpd to do the TLS termination (which it's pretty
obvious you are in fact trying to do).

> So now I have a Connector to receive the port 80 traffic and
> another for the port 443 traffic. I've tried it with and without
> the redirectPort attribute. Still no success.

Okay. This is IMO the best configuration especially if you want to
treat some applications as secure and others as insecure. (In my
environment, everything is secure, so I use only a single Connector.)

> The Connectors appear in this order in server.xml
> <Connector port="8081" protocol="HTTP/1.1" 
> connectionTimeout="20000" proxyName="" 
> proxyPort="80" redirectPort="8443" xpoweredBy="false" 
> server="Apache TomEE" /> <Connector port="8082"
> protocol="HTTP/1.1" connectionTimeout="20000" 
> proxyName="" proxyPort="443" redirectPort="8443" 
> xpoweredBy="false" server="Apache TomEE" />

I think you want redirectPort="443" for both of those connectors.
Assuming that you want port 8082 to be used for proxying HTTPS
connections, you are going to want to set these attributes at well:


This will let your application know that the connection is secure (but
it's up to you to make sure that it actually IS by not e.g. proxying a
non-TLS connection to port 8082).

There are ways to get this to work with a single connector and have
the reverse proxy (that's httpd_+mod_proxy, here) tell Tomcat what
kind of connection it is. But you have to configure a proxy listener
and configure more stuff on the httpd end. That's one of the reasons I
like mod_jk better since it automatically sends all that stuff to the

Something you aren't getting unless you are using the RemoteIPValve[1]
is the ability to tell anything about the client's connection (origin
IP, protocol, etc.) as well as possibly the hostname they were
requesting. I have much less experience with mod_proxy_http than I do
with mod_proxy_ajp/mod_jk which "just handles it". I would recommend
using the RemoteIPValve on the Tomcat end.

> Note: It is curious to me that when I enter 
> into a browser, Apache serves the page at /var/www/html/index.html 
> which is in the document root defined in
> /etc/httpd/conf/httpd.conf with the directive DocumentRoot
> "/var/www/html"

Why is that curious?

> My expectation is that the call to would be 
> redirected with the pair ProxyPass / 
> ProxyPassReverse / in the virtual host
> element for port 443.

I'll bet that a file in the DocumentRoot takes precedence over the
proxy configuration. Someone with a better understanding of the
internals of httpd would have to comment on that. I *always* proxy a
sub-path and never the root... otherwise, what's the point of having
the reverse proxy in the first place?

> To refresh, the virtual host definitions are currently:
> <VirtualHost *:80> ServerName ServerAlias
> * ProxyRequests off ProxyPreserveHost on ProxyPass
> / ProxyPassReverse  /
> ProxyPass         /mycontext
> ProxyPassReverse  /mycontext
> ProxyPass         /anotherContext
> ProxyPassReverse
> /anotherContext 
> </VirtualHost>

Okay, that probably won't work (unless it will!). I believe that
ProxyPass directives match in the order in which they are present in
the file: first one wins. So after our first ProxyPass directive, the
others are irrelevant. Since you have them all pointing to the same
place, it probably doesn't matter in this case. But you should know
that the /mycontext and /anothercontext mappings are always being
ignored. If you wanted them to matter, you would have to reverse them:

  ProxyPass         /mycontext
  ProxyPassReverse  /mycontext
  ProxyPass         /anotherContext
  ProxyPassReverse  /anotherContext
  ProxyPass         /
  ProxyPassReverse  /

That way, the longer context-names are matched (and proxied) first.

> <VirtualHost *:443> ServerName ServerAlias
> * <Proxy *> Order deny,allow Allow from all </Proxy>

That <Proxy> section looks worthless, since you don't have any other
allow/deny directives.

> ProxyRequests off

This is the default. I'm not sure it's worth putting into your

> ProxyPreserveHost on

This is essential, if you are going to have Tomcat manage virtual
hosts (which you are doing).

> CustomLog "/etc/httpd/logs/examplessl.log" "%h %l %u %t \"%r\" %>s
> %b" ErrorLog "/etc/httpd/logs/examplessl_error.log" SSLEngine on 
> SSLProxyEngine on SSLCertificateFile
> /etc/pki/tls/certs/certfile.crt SSLCertificateKeyFile
> /etc/pki/tls/private/example.key ProxyRequests off 
> ProxyPreserveHost on


> ProxyPass / ProxyPassReverse /
> ProxyPass         /mycontext
> ProxyPassReverse  /mycontext
> ProxyPass         /anotherContext
> ProxyPassReverse
> /anotherContext 
> </VirtualHost>

Same ordering issue down here: reverse those or just proxy / and be
done with it.

> Any other thoughts as to what I may not be seeing here? I think
> I've read the docs exhaustively. Your responses are much
> appreciated.

Enable the RemoteIPValve in your <Engine> in Tomcat. I think that will
help tremendously.

If it's not super-important to manage multiple virtual hosts on the
Tomcat side, I'd simplify your configuration and remove the virtual
host stuff from Tomcat. For example, if all your context names are
unique across all virtual hosts (including / !!) then you can
seriously simplify everything.

- -chris

Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -


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

View raw message