httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luke Meyer <>
Subject RE: mod_proxy{,_ajp} clarification suggestion
Date Tue, 05 Apr 2011 18:31:08 GMT
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 [] 
Sent: Thursday, May 13, 2010 4:17 PM
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:

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, 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.

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


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

View raw message