httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Meyer <>
Subject mod_proxy{,_ajp} clarification suggestion
Date Thu, 13 May 2010 20:16:32 GMT
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:

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:

ProxyPass /apps/ ajp://localhost:8009/apps/
ProxyPassReverse /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:

ProxyPass /apps/ ajp://localhost:8009/
ProxyPassReverse /apps/


A second area that I would like clarified is around ProxyPassReverseCookiePath: the documentation
at 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. 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.

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message