[Mod_gzip] mod_gzip + mod_proxy in forward proxy mode

[mod_gzip@lists.over.net]

Hi Jason,


> I'm using apache 2.0.48, mod_gzip 2.0.40. What I aim to do is to use
mod_gzip,
> mod_proxy (in forward proxy mode) to compress some of the HTTP objects
like
> html, doc files. No caching is involved. So the Apache would be like a
general
> forward proxy server with compression feature for particular objects.
>
> I confirmed that mod_gzip can compress the objects from mod_proxy too.
But it
> was not 100% successful. It could compress only *small* HTML pages (less
than,
> approximately 1K) successfully. For the bigger HTML, however, the HTML
body was
> not correctly encoded, even though the response has "Content-Encoding:
gzip"
> header.
>
> By "not correctly" I mean that the HTML body does begin with gzip
signature
> (1F 8B ...), but in the body HTML tags are clearly visible! It was not
encoded.
> Of course browser can't analyze it, failing to display it on the screen.
It is
> definitely working, but something is wrong.
>
> In fact, before I moved on to mod_gzip, I tried mod_deflate to do what I
wanted
> to do, since, as you said, mod_deflate was already included in the apache
> distribution. I can tell you the result right now : mod_deflate was not
> designed to work with mod_proxy. It can compress the content if the
apache is
> serving files from local machine, but it doesn't compress HTML objects
from the
> others. After that I also remeber I read an article on the web saying
> mod_deflate cannot work with mod_proxy, which confirmed what I observed.
> There was no magic directive like "mod_gzip_item_include handler
proxy-server".

I am far from being an expert of Apache 2.0's filtering mechanism
but as far as I have read its documentation (which is currently
translated to my native language...) I wonder how mod_deflate
could be "designed to work with mod_proxy", because I don't see
what a filter could do in this aspect except for reading some input
stream and writing some output stream.
And mod_deflate is surely capable of compressing dynamic content
(CGI and the like), so it should not matter where its input came from
as long as it were a legal "stream" in respect to the filter mechanism.

So the question might rather be whether Apache 2.0*s filtering
mechanism as a whole was designed to work with mod_proxy, or
maybe the other way round - was mod_proxy designed to provide
content for arbitrary filter modules?

As I am not able to answer that, I put Ian Holsman, the author of
mod_deflate, as a cc: to this posting, so maybe he could explain
what happens there. Configuring filters provides some tricky
features so I still hope something can be done, like configuring
the right internal filter priority or whatnot.
He might also be the right person to help finding out whether you
have located some Apache filtering bug or some bug in mod_gzip
2.0.40 (or maybe simply some incompatibility between the filtering
APIs of 2.0.40 and 2.0.48 - maybe mod_gzip 2.0.4x needs another
upgrade?).

I would be surprised if there were a difference between mod_deflate
and mod_gzip in the respect of handling mod_proxy content, as both
are Apache 2.0 filters and would use the same API, so we should
ask the Apache filter experts about that anyway.
I have more hope to get the thing running with mod_deflate first,
which might then supply valuable information about how to make
it run with mod_gzip as well.

Of course, you might post the mod_deflate problem to the Apache
support mailing list as well, but maybe having Ian 'on board' could
suffice already.

Regards, Michael