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. 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: [email protected] For additional commands, e-mail: [email protected]
