tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: AJP config questions
Date Fri, 15 May 2015 12:02:47 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Jeffrey,

On 5/14/15 6:38 PM, Jeffrey Janner wrote:
> (Hopefully, this isn't a duplicate post, but I sent the original a 
> half-hour ago and I haven't seen it come back yet.)
> 
> Guys, it's been a long time since I did any work with AJP, but it 
> looks like something I'll be implementing soon. I have a couple of
> basic questions, mostly related to ProxyPassReverse, but also one
> related to SSL.
> 
> I know to turn on mod_proxy and mod_proxy_ajp and a simple
> ProxyPass where the source and dest paths match, i.e. both are
> "/foo". The question is if they differ. The httpd docs give this
> example:
> 
> Rewriting Proxied Path ProxyPass /apps/foo
> ajp://backend.example.com:8009/foo ProxyPassReverse /apps/foo
> http://www.example.com/foo
> 
> but don't mention if you need to turn on the RewriteEngine. Also,
> the second line doesn't look correct. Shouldn't it be 
> http://www.example.com/app/foo? Or maybe
> ajp://backend.example.com:8009/foo?

Trying to re-name the context path during proxying is a road that ends
in tears. ProxyPassReverse only re-writes headers like SetCookie and
Location. If you have links within your pages, you'll need to use
something like mod_html to re-write all of them as the page is
streamed back to the client.

Best practice is to re-name the application to apps#foo.war if that's
really the URL path you want to use.

(The above configuration does not use mod_rewrite, hence the absence
of "RewriteEngine On".)

> BTW: we don't seem to be able to get the example to work. 
> "ProxyPass /myapp ajp://localhost:8009/myapp"  works, but 
> "ProxyPass /app ajp://localhost:8009/myapp" does not work, and
> we've tried various iterations of ProxyPassReverse with it.

When you say "doesn't work", what do you really mean?

> What's the best way to handle ROOT.war, assuming there are other 
> webapps to deploy as well?

This is tough. I would recommend that you put all web applications in
distinct paths, and not use ROOT at all. It makes proxying a little
more sane IMHO. You can definitely still do it (just do all your
ProxyPasses for the non-ROOT webapps *first* in httpd.conf, and then
have one that does something like "ProxyPass / [endpoint]" last to
handle the ROOT webapp.

> What if I don't want ROOT.war, but want to send / to a specific
> webapp?

Put index.html into ROOT/index.html and do a redirect (or something
roughly equivalent, like using RedirectMatch ^/$ /webapp/).

> SSL Question: Since our web.xml is configured to redirect all
> requests to SSL in the <security-constraints> area, how does that
> effect the options that need to be supplied in the connector? Right
> now, we just have the basic config as it comes in the initial
> conf.xml.

When using mod_proxy_ajp, the SSL information should be passed-over
from httpd to Tomcat just like when you are using mod_jk, so I don't
think you'll get a redirect storm. mod_jk sends-over some extra stuff
by default that mod_proxy_ajp I think does not, but I can't remember
off the top of my head what those things are.

> Sorry for being a newbie on this, but the last time I messed with 
> Apache proxy was 4.0 and then I used JK.

You can still certainly use mod_jk, but you'll find the same issues
with path-rewriting. I've been using mod_jk forever and I have no
plans to abandon it. mod_jk is alive and well if you'd prefer to use
something with which you have previous experience.

But you do have to build it separately, since it doesn't come bundled
with httpd (which is definitely a bummer).

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVVeBnAAoJEBzwKT+lPKRYsAwP/086jW4zeX/5BZxJyMsEbjLp
fEJCj8tJguyKoXRkgVIqeVW9aHK86elY3JYaAx/00GmrZACZbk2J963XB58E3YyV
C3bd3K1BkHGYsWCoYwqEcNUIygnaJEuWrydXalcJrvrsk5vprkkFKQE/yu2Wu7gg
vdNcbLe+LwySbYAJdzrBWYiyTFqarA/ShFkyMcpsEz+TWpbcDZptfpLLs2M30lPz
/53OaJvfVs4yle/nXaqvG7R61RXc1/JkEOVApXMhn+lCnP2XBwNhVtpqsAjwIRMv
ArdZClXH5wEpB+8rwWZVwMVQhJZJqGZXjBX8k9r1zNoXzomN6TWnB6zcnjOBpMVC
RaErv9KQmSDsRWwmz5wyhdHWNPOVo48g0oCZhg22cF4tCXd879x25P4HIEyR5hT/
oJppa8kT7nSSaRQbq3s0n1LrBUMa7FqF+544zID6HnATSlNVADP5DOMUFrrEU+yH
sAtsKsdjeuvO01FsI7f246vtwZ4VbXu8UfFswgFanHFFLGV0oLOOHbYyNEQF5tVU
VeAsAMAg4dkNplW70XL4CGXho7WVEauCoivWVYxIvgQXyBA8q1NO89ZwGHO2wE5L
lODTZ/16d/pI3VTxZJB10ENpVFQrpoXZz4Qaq24UCI6cli4OVGlBuelsCzgocga3
0T/nQcypPZ7IMQB4B0wy
=ZtFn
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message