Am 14.05.2015 um 23:58 schrieb Jeffrey Janner:
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.
No you don't. ProxyPass and ProxyPassReverse and also any other Proxy*
directive are implemented without using mod_rewrite.
Also, the second line doesn't look correct. Shouldn't it be
http://www.example.com/app/foo?
No. ProxyPass is used when mapping and transforming a request.
ProxyPassReverse is used when mapping the "LocatioN" header *if* it is
part of the response. In that case the response is a HTTP redirect and
location points to the new address. Your backend will likely use its own
address as it knows it. The backend (servlet enfine) does not know about
ajp://backend.example.com. When using AJP, the servlet engine uses the
web server protocol, host name and port to build a self-referential URL,
but will use the context path that is really used on the backend.
BTW: we don't seem to be able to get that 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.
hard to tell, because you haven't said what "does not work" means, and
you now also switched from a previous incomplete example using a
balancer to another incomplete one without a balancer.
You can test ProxyPass first, then ProxyPassReverse. ProxyPassReverse
does not influence, whether your request is forwarded and how it will
look like at the backend. It only changes an optional Locatoin header in
the response. So if you look at your response with a client that doesn't
follow redirects, you can check, whether your requests hits the backend,
you get back a response and whether it looks like what you want.
Note that if links embedded in your responses are wrong (e.g. point at
/myapp instead of /app) then things get messy and you would need to use
and configure mod_substitute or mod_sed or mod_proxy_html to scan
through all of your responses and dynamically replace the links in it.
You might also be interested in ProxyPassReverseCookiePath, which fixes
path attributes of cookies, so again a response header only thing.
What's the best way to handle ROOT.war, assuming there are other webapps to
deploy as well?
I don't understad this question.
What if I don't want ROOT.war, but want to send / to a specific webapp?
ProxyPass / ajp://localhost/myapp/
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.
I can't tell what "how does that effect the options that need to be
supplied in the connector" means, because I don't know what result you
want to get.
In general ajp itself is always non-encrypted. Whether the backend sends
a redirect to an https URL due to the security-constraint or not depends
on whether you already talk https to the web server or not. If you
already use https then ajp transports this information via ajp and the
backend will not issue a redirect. If you talk http to the web server,
then the security-constraint will issue a redirect. If the context path
in the redirect is wrong, ProxyPassReverse can fix it.
Sorry for being a newbie on this, but the last time I messed with Apache proxy
was 4.0 and then I used JK.
NP. Just keep in mind, that mod_jk and mod_proxy_ajo use the same AJP
protocol. What differs is how it works to change path segments in
requests, responses and headers. mod_proxy has specific directives for
that, mod_jk not.
Although not describing mod_proxy, the page
http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html
might be helpful. Where mod_jk and mod_proxy differ a lot is the "URL
Rewriting" part, the "AJP as a Solution" is the same or at least very
similar.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
