Re: Tomcat behind Apache reverse proxy
On 11.08.2009 15:37, Rainer Frey wrote: On Tuesday 11 August 2009 10:40:48 Mark Thomas wrote: Rainer Frey wrote: With AJP, isn't that information also available in the protocol request and set automatically by the AJP connector? I believe so. I tried, and it works. Does it make sense to set these attributes at all on an APR connector then? Some general information about this situation is contained in the mod_jk docs page: http://tomcat.apache.org/connectors-doc/generic_howto/proxy.html It is mostly about AJP13, HTTP and reverse proxies and not mod_jk specific. Regards, Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat behind Apache reverse proxy
We develop an application that is heavily using different kind of web services
(SOAP, Hessian) and only has few JSPs that are used with a browser. We bundle
Tomcat (6.0.20) as server runtime.
Some customers (with varying degree of experience) want to use this behind
Apache HTTPD as reverse proxy and ask us for instructions.
What would you recommend to describe in a general instruction document without
knowing more details of the customers environment, mod_proxy_http or
mod_proxy_ajp? (I think mod_jk is an option mostly for knowledgable customers
who have specific reasons to consider it).
I also try to keep the need for a customer to edit server.xml as a minimum,
and put as much of the customizable values into catalina.properties.
What is the effect of not setting proxyName and proxyPort on the connector in
either case? Would that lead to invalid redirects? (Our application doesn't
use ServletRequest#getServerName() or #getServerPort() directly.) With AJP,
isn't that information also available in the protocol request and set
automatically by the AJP connector?
I also have an ideo for a (maybe dirty) hack: if I always put the proxyName
and proxyPort attributes in server.xml, and use properties that expand to
empty values by default, will this work in case there is no proxy in the
setup?
e.g. in server.xml:
Connector proxyName=${proxy.name} proxyPort=${proxy.port} .../
and in catalina.properties:
proxy.name=
proxy.port=
Thanks for any input
Rainer
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat behind Apache reverse proxy
Rainer Frey wrote: Some customers (with varying degree of experience) want to use this behind Apache HTTPD as reverse proxy and ask us for instructions. What would you recommend to describe in a general instruction document without knowing more details of the customers environment, mod_proxy_http or mod_proxy_ajp? (I think mod_jk is an option mostly for knowledgable customers who have specific reasons to consider it). If the customer has done this before, whatever they are familiar with. If I had a free choice mod_proxy_http. What is the effect of not setting proxyName and proxyPort on the connector in either case? Would that lead to invalid redirects? (Our application doesn't use ServletRequest#getServerName() or #getServerPort() directly.) Potentially, yes. With AJP, isn't that information also available in the protocol request and set automatically by the AJP connector? I believe so. I also have an ideo for a (maybe dirty) hack: if I always put the proxyName and proxyPort attributes in server.xml, and use properties that expand to empty values by default, will this work in case there is no proxy in the setup? Have you tried it? Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat behind Apache reverse proxy
On Tuesday 11 August 2009 10:40:48 Mark Thomas wrote: Rainer Frey wrote: Some customers (with varying degree of experience) want to use this behind Apache HTTPD as reverse proxy and ask us for instructions. What would you recommend to describe in a general instruction document without knowing more details of the customers environment, mod_proxy_http or mod_proxy_ajp? (I think mod_jk is an option mostly for knowledgable customers who have specific reasons to consider it). If the customer has done this before, whatever they are familiar with. If I had a free choice mod_proxy_http. Thanks for this input. Do you have any technical reasons, or is it more about maturity of the module? With AJP, isn't that information also available in the protocol request and set automatically by the AJP connector? I believe so. I tried, and it works. Does it make sense to set these attributes at all on an APR connector then? I also have an idea for a (maybe dirty) hack: if I always put the proxyName and proxyPort attributes in server.xml, and use properties that expand to empty values by default, will this work in case there is no proxy in the setup? Have you tried it? I did now, and it does work. I noticed that property expansion in server.xml seems not to be documented at all. Is this intentionally left out, or just missing? Also, properties from catalina.properties and from Java System Properties are expanded, but it seems that catalina.properties takes precedence. I find this surprising, because system properties are in my perception more dynamic and runtime/individual start specific than values in a config file. Is this intentional behavior? If not, should I report a bug? Mark Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat behind Apache reverse proxy
On Tuesday 11 August 2009 15:37:54 Rainer Frey wrote: Also, properties from catalina.properties and from Java System Properties are expanded, but it seems that catalina.properties takes precedence. I find this surprising, because system properties are in my perception more dynamic and runtime/individual start specific than values in a config file. Is this intentional behavior? If not, should I report a bug? Out of curiosity: does anyone know where in the source the expansion of catalina.properties in server.xml is implemented? Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat behind Apache reverse proxy
Rainer Frey wrote: On Tuesday 11 August 2009 10:40:48 Mark Thomas wrote: Rainer Frey wrote: Some customers (with varying degree of experience) want to use this behind Apache HTTPD as reverse proxy and ask us for instructions. What would you recommend to describe in a general instruction document without knowing more details of the customers environment, mod_proxy_http or mod_proxy_ajp? (I think mod_jk is an option mostly for knowledgable customers who have specific reasons to consider it). If the customer has done this before, whatever they are familiar with. If I had a free choice mod_proxy_http. Thanks for this input. Do you have any technical reasons, or is it more about maturity of the module? Only that mod_proxy_* should be more familiar to httpd admins and mod_proxy_http is more mature than mod_proxy_ajp. With AJP, isn't that information also available in the protocol request and set automatically by the AJP connector? I believe so. I tried, and it works. Does it make sense to set these attributes at all on an APR connector then? Usually not. I also have an idea for a (maybe dirty) hack: if I always put the proxyName and proxyPort attributes in server.xml, and use properties that expand to empty values by default, will this work in case there is no proxy in the setup? Have you tried it? I did now, and it does work. I noticed that property expansion in server.xml seems not to be documented at all. Is this intentionally left out, or just missing? Missing. Also, properties from catalina.properties and from Java System Properties are expanded, but it seems that catalina.properties takes precedence. I find this surprising, because system properties are in my perception more dynamic and runtime/individual start specific than values in a config file. Is this intentional behavior? If not, should I report a bug? It isn't documented so there can't be a bug :) Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat behind Apache reverse proxy
Rainer Frey (Inxmail GmbH) wrote: On Tuesday 11 August 2009 15:37:54 Rainer Frey wrote: Also, properties from catalina.properties and from Java System Properties are expanded, but it seems that catalina.properties takes precedence. I find this surprising, because system properties are in my perception more dynamic and runtime/individual start specific than values in a config file. Is this intentional behavior? If not, should I report a bug? Out of curiosity: does anyone know where in the source the expansion of catalina.properties in server.xml is implemented? org.apache.tomcat.util.IntorspectionUtils.replaceProperties() Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat behind Apache reverse proxy
On Tuesday 11 August 2009 16:10:07 Mark Thomas wrote: Rainer Frey wrote: [...] Mark, thanks for your patient help with my questions. I really appreciate this. Also, properties from catalina.properties and from Java System Properties are expanded, but it seems that catalina.properties takes precedence. I find this surprising, because system properties are in my perception more dynamic and runtime/individual start specific than values in a config file. Is this intentional behavior? If not, should I report a bug? It isn't documented so there can't be a bug :) Touch. That is indeed right ;-) But seriously, how is it intended to work? I saw that in CatalinaProperties.loadProperties(), all properties from catalina.properties are added to the system properties, overwriting any previous values. This could be easily fixed. I'd write a patch myself if desired. Rainer - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat behind Apache reverse proxy
Rainer Frey wrote: On Tuesday 11 August 2009 16:10:07 Mark Thomas wrote: Rainer Frey wrote: [...] Mark, thanks for your patient help with my questions. I really appreciate this. Also, properties from catalina.properties and from Java System Properties are expanded, but it seems that catalina.properties takes precedence. I find this surprising, because system properties are in my perception more dynamic and runtime/individual start specific than values in a config file. Is this intentional behavior? If not, should I report a bug? It isn't documented so there can't be a bug :) Touch. That is indeed right ;-) But seriously, how is it intended to work? I saw that in CatalinaProperties.loadProperties(), all properties from catalina.properties are added to the system properties, overwriting any previous values. This could be easily fixed. I'd write a patch myself if desired. Changing this at this stage is probably a bad idea. It is bound to break something for someone. I'd go with a documentation patch to add the current behaviour to the docs. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
