[Mod_gzip] mod_gzip + mod_proxy in forward proxy mode

J Kim mod_gzip@lists.over.net
Tue, 16 Dec 2003 23:05:09 +0900 (JST)


Hello Michael,

> 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

Neither am I. I came to that conclusion with my own experiment and the document
I found on the web(I hope this is a creditable one):

http://pflanze.mine.nu/~chris/mod_deflate/mod_deflate_readme_EN.html

In which it says:

Known errors and the special feature 
mod_deflate does not compress the responses, which passed through mod_proxy,
since mod_proxy for the return of the response to client does not use a
function of ap_send_HTTP_header().At the same time, the responses of mod_proxy,
put with the aid of you mod_reshrite into the SSI- documents, they are
compressed. 

Thank you for putting the author the mod_deflate on this board. As you said he
must be the right person who can answer to the question whether mod_deflate is
able to work with mod_proxy.

Jason J Kim


 --- Michael.Schroepl@telekurs.de wrote: > 
> 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
> 
> _______________________________________________
> mod_gzip mailing list
> mod_gzip@lists.over.net
> http://lists.over.net/mailman/listinfo/mod_gzip 

_____________________________________________________________________
¿¹»Û ÆíÁöÁö¿¡ ¸ÞÀÏÀ» º¸³»¼¼¿ä - ¾ßÈÄ! ¸ÞÀÏ
http://mail.yahoo.co.kr
½ÅÂ÷,Áß°íÂ÷,Á÷°Å·¡ ¸Å¹°ÀÌ ÇÑÀÚ¸®¿¡ - ¾ßÈÄ! ÀÚµ¿Â÷
http://autos.yahoo.co.kr/autos/