On Thu, 2008-02-21 at 21:30 +0100, Udo Rader wrote: > Hi, > > I have the following setup: > > an externally reachable https server with mod_proxy enabled that should > reverse proxy requests to other servers within the DMZ: > > inet ---> https reverse proxy ---> http hosts > > Now everything "almost" works, except for some (not all) urls not > correctly rewritten, most notably stylesheet urls. > > When the orginal (internal) url would look like > > http://internal.example.com/css/style.css > > the reverse proxy converts it into > > http://reverseproxy.example.com/css/style.css > > instead of the correct > > https://reverseproxy.example.com/css/style.css > > Unfortunately I don't seem to be able to overcome this problem, so maybe > someone else has an idea ... > > My reverse proxying configuration looks like this: > > --------CUT------- > ProxyPass /someApp/ http://internal.example.com/someApp/ > ProxyHTMLURLMap http://internal.example.com/someApp/ /someApp > > <Location /someApp/> > ProxyPassReverse / > SetOutputFilter proxy-html > ProxyHTMLURLMap / /someApp/ > ProxyHTMLURLMap /someApp /someApp > </Location> > --------CUT------- > > As you see, I've also included mod_proxy_html, but that does not change > anything.
So in order to solve the riddle myself, the problem was really well hidden and not due to a the configuration I posted above. The problem was that I had mod_deflate globally enabled for the https host (being not only a reverse proxy but also a "regular" webserver as well), resulting in mod_deflate obviously having some precedence over mod_proxy_html and that again resulting in mod_proxy_html not converting anything. Disabling mod_deflate globally and enabling it only where I really needed it, solved the problem. However, this looks like a mod_proxy_html <=> mod_deflate interaction problem. -- Udo Rader bestsolution.at EDV Systemhaus GmbH http://www.bestsolution.at >
signature.asc
Description: This is a digitally signed message part
