Antwort: Re: [Mod_gzip] mod_gzip with mod_ssl (using mod_proxy)

[mod_gzip@lists.over.net]

Hi Matt,


> This doesn't work either. I've proved that the proxy is actually
> working and passing requests to the specified target, its just
> that mod_gzip isn't working on those requests - which implies
> that it has been encrypted before being passed through the proxy.

you are doing the SSL encryption on the 'outside' and the
compression on the 'inside'.
So let's just trace the way your request is going - at least
this is how it should be, I guess:

1. The request is received 'outside' and the SSL encoding
   is removed by mod_ssl (we are not yet doing HTTP, but
   still HTTPS). After that, we enter the HTTP universe.
2. Apache maps the URL to a path and detects that this
   request has to be handled by mod_proxy.
3. mod_proxy translates the request and issues another
   request (now HTTP) to the 'inner' virtual host.
   You must be able to track this request in the access_log
   of the 'inner' virtual host.
4. Again, Apache is evaluating what to do with the URL and
   maps it to whatever your 'inner' Virtual Host's configu-
   ration tells it.
5. Now is the time for mod_gzip to step in: It processes
   the first phase of its rule checking ("file", "uri",
   "handler" and "reqheader" rules") - unless some other
   module has stolen away the request from mod_gzip (which
   depends on the load sequence of the modules).
   If mod_gzip declines the request here, it writes a
   "DECLINED:" type status code into access_log.
6. Whatever has to be done to create a response for this
   request comes in this step.
7. If mod_gzip didn't already decline the request, it will
   now start its second rule evaluation phase, checking
   the "mime" and "rspheader" rules (which wasn't possible
   earlier, obviously).
   If mod_gzip rejects to compress the response here, it
   writes a "SEND_AS_IS:" type status code into access_log.
8. Now the result can finally be transferred back to the
   caller - which has been the mod_proxy of the 'outer'
   Apache, whose turn it is to simply receive the response
   and possibly do some translation for the HTTP headers
   (which might contain redirections and the like).
9. And finally the SSL encoder gets his shot at the re-
   sponse and wraps it with its layer, before it is then
   sent to the client (or whichever proxy server has been
   the next link in the transport chain) as HTTPS response.

So if you cannot find any traces of the response inside

the inner Apache that would be a miracle to me, as this

inner Virtual Host shouldn't care whether the "client"

was a browser or a mod_proxy.

If you can, then the mod_gzip status code should tell

you what has happened and whether mod_gzip interfered

with some other Apache module - but not SSL.

(Remember: Resolving the conflict between SSL and mod_gzip

within _the same_ request handling was the reason why we

needed two Virtual Hosts at all, and two requests ...)



Regards,

      Michael