RE: mod_proxy{,_ajp} clarification suggestion

[Luke Meyer <lm...@vmware.com>]

I was wondering if anyone could give me a pointer on this. I wouldn't mind working up docs patches, just not sure where they would best go.

-----Original Message-----
From: Luke Meyer [mailto:lmeyer@vmware.com] 
Sent: Thursday, May 13, 2010 4:17 PM
To: docs@httpd.apache.org
Subject: mod_proxy{,_ajp} clarification suggestion

Hello docs,

I came across this while helping a customer with their proxy configuration. I think it would be a good idea to clarify how mod_proxy_ajp works where it is counter to expectations for those from a mod_proxy_http background. I don't know if this would best go in the mod_proxy documentation for ProxyPassReverse, in mod_proxy_ajp docs, or somewhere else.

For background, have a look at this: http://www.humboldt.co.uk/2009/02/the-mystery-of-proxypassreverse.html

What I would like to see clarified:

--------------------------------------

Mod_proxy_ajp does not make a secondary http request to the backend like mod_proxy_http; aside from the URI, it passes on the initial request unchanged (aside from encoding), and in particular the Host: header remains the same indicating the proxy host (which is as it must be). The backend will typically use this in constructing redirects, so any use of ProxyPassReverse should be using the proxy host to match, not some version of the backend host. Example:

ServerName www.example.com
ProxyPass /apps/ ajp://localhost:8009/apps/
ProxyPassReverse /apps/ http://www.example.com/apps/

In fact, in this case the ProxyPassReverse is not even necessary because a redirect response header would reference the original proxy host. It is only required if ProxyPass is rewriting the path from the proxy to a different path on the backend, for example:

ServerName www.example.com
ProxyPass /apps/ ajp://localhost:8009/
ProxyPassReverse /apps/ http://www.example.com/

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

A second area that I would like clarified is around ProxyPassReverseCookiePath: the documentation at http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassreversecookiepath says:

"Usage is basically similar to ProxyPassReverse, but instead of rewriting headers that are a URL, this rewrites the path string in Set-Cookie headers."

This is misleading. "Similar" perhaps but significantly different. Add this to the second example above:

ProxyPassReverseCookiePath / /apps

This does not prepend "/apps" to the cookie's path, according to my experiments; it replaces it entirely. It is not doing a match-and-replace like ProxyPassReverse; instead it replaces the path completely if it matches. This could be problematic if you have a lot of applications on the backend web server each wanting to preserve its own session cookie by setting a path. It would require a specific directive for each application e.g.

ProxyPassReverseCookiePath /app1 /apps/app1
ProxyPassReverseCookiePath /app2 /apps/app2
...

I would go so far as to call this a bug; certainly I think it should work more like ProxyPassReverse. In the meantime, perhaps the docs could instead read:

--------------------------------------------

Useful in conjunction with ProxyPassReverse in situations where internal paths must be rewritten to public paths. Instead of rewriting headers that are a URL, this rewrites the path string in Set-Cookie headers. If the beginning of the cookie path matches internal-path, the cookie path will be set to public-path.

EXAMPLE:
ProxyPassReverseCookiePath / /apps
This will rewrite a cookie with path /example to /apps.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^



---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org

Re: mod_proxy{,_ajp} clarification suggestion

[Rich Bowen <rb...@rcbowen.com>]

I think, at least initially, it should to in the manual/mod/mod_proxy_ajp.xml doc. However, it would be awesome to (eventually) have a complete proxy section that addresses stuff like this, includes a full reverse-proxy howto, talks about load balancing, and so on.

On Apr 5, 2011, at 2:31 PM, Luke Meyer wrote:

> I was wondering if anyone could give me a pointer on this. I wouldn't mind working up docs patches, just not sure where they would best go.
> 
> -----Original Message-----
> From: Luke Meyer [mailto:lmeyer@vmware.com] 
> Sent: Thursday, May 13, 2010 4:17 PM
> To: docs@httpd.apache.org
> Subject: mod_proxy{,_ajp} clarification suggestion
> 
> Hello docs,
> 
> I came across this while helping a customer with their proxy configuration. I think it would be a good idea to clarify how mod_proxy_ajp works where it is counter to expectations for those from a mod_proxy_http background. I don't know if this would best go in the mod_proxy documentation for ProxyPassReverse, in mod_proxy_ajp docs, or somewhere else.
> 
> For background, have a look at this: http://www.humboldt.co.uk/2009/02/the-mystery-of-proxypassreverse.html
> 
> What I would like to see clarified:
> 
> --------------------------------------
> 
> Mod_proxy_ajp does not make a secondary http request to the backend like mod_proxy_http; aside from the URI, it passes on the initial request unchanged (aside from encoding), and in particular the Host: header remains the same indicating the proxy host (which is as it must be). The backend will typically use this in constructing redirects, so any use of ProxyPassReverse should be using the proxy host to match, not some version of the backend host. Example:
> 
> ServerName www.example.com
> ProxyPass /apps/ ajp://localhost:8009/apps/
> ProxyPassReverse /apps/ http://www.example.com/apps/
> 
> In fact, in this case the ProxyPassReverse is not even necessary because a redirect response header would reference the original proxy host. It is only required if ProxyPass is rewriting the path from the proxy to a different path on the backend, for example:
> 
> ServerName www.example.com
> ProxyPass /apps/ ajp://localhost:8009/
> ProxyPassReverse /apps/ http://www.example.com/
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> A second area that I would like clarified is around ProxyPassReverseCookiePath: the documentation at http://httpd.apache.org/docs/2.2/mod/mod_proxy.html#proxypassreversecookiepath says:
> 
> "Usage is basically similar to ProxyPassReverse, but instead of rewriting headers that are a URL, this rewrites the path string in Set-Cookie headers."
> 
> This is misleading. "Similar" perhaps but significantly different. Add this to the second example above:
> 
> ProxyPassReverseCookiePath / /apps
> 
> This does not prepend "/apps" to the cookie's path, according to my experiments; it replaces it entirely. It is not doing a match-and-replace like ProxyPassReverse; instead it replaces the path completely if it matches. This could be problematic if you have a lot of applications on the backend web server each wanting to preserve its own session cookie by setting a path. It would require a specific directive for each application e.g.
> 
> ProxyPassReverseCookiePath /app1 /apps/app1
> ProxyPassReverseCookiePath /app2 /apps/app2
> ...
> 
> I would go so far as to call this a bug; certainly I think it should work more like ProxyPassReverse. In the meantime, perhaps the docs could instead read:
> 
> --------------------------------------------
> 
> Useful in conjunction with ProxyPassReverse in situations where internal paths must be rewritten to public paths. Instead of rewriting headers that are a URL, this rewrites the path string in Set-Cookie headers. If the beginning of the cookie path matches internal-path, the cookie path will be set to public-path.
> 
> EXAMPLE:
> ProxyPassReverseCookiePath / /apps
> This will rewrite a cookie with path /example to /apps.
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
> For additional commands, e-mail: docs-help@httpd.apache.org
> 

--
Rich Bowen
rbowen@rcbowen.com
rbowen@apache.org
PGP Key ID CC78C893





---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org