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:[email protected]] > Sent: Thursday, May 13, 2010 4:17 PM > To: [email protected] > 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: [email protected] > For additional commands, e-mail: [email protected] > -- Rich Bowen [email protected] [email protected] PGP Key ID CC78C893 --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
