Am 15.05.2015 um 02:11 schrieb Rainer Jung:
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.
I should probably add: ProxyPassReverse maps from right to left. So
ProxyPassReverse /apps/foo http://www.example.com/foo
takes any Location header whose value starts with
"http://www.example.com/foo"; and then removes that value, sticks
"/apps/foo" in front instead and adds protocol, host and port according
to the local Apache VHost that forwarded the request.
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
