RE: AJP config questions
Thanks for the guidance guys. I understand it better. See in-line comments: > -Original Message- > From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Sent: Friday, May 15, 2015 7:03 AM > To: Tomcat Users List > Subject: Re: AJP config questions > > -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 Means we can't reach the app on the Tomcat side. > > > 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. This will be very helpful, since the primary app is currently deployed as ROOT. (We are using Tomcat direct connections, but moving to an HTTPD front-end for a few deployments.) > > > 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 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. > OK, I was just wondering what parameters need to be set in the for AJP and if any needed to be specified for the whole redirect to SSL thingy. I'm guessing it still needs a redirect parameter in the above case? Re-reading the documentation. > > 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 >
Re: AJP config questions
-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 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AJP config questions
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 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.apach
Re: AJP config questions
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 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
