Hi Eli... This is Kevin Kiley > You wrote... > >Hi Kevin/Ralf/etc., > >Until recently, it was impossible to manipulate Apache responses (other >than static content which a module can be written to serve) without >patching the core Apache. Apache 2.0 tries to overcome this problem, but >modules like mod_ssl had to insert many patches into the core source, a >painful requirement, and also a dependency on any version of Apache, and >need to update mod_ssl for any new version of Apache. > >mod_gzip pretends to solve this problem. There is no 'pretend'. It does it. mod_gzip basically proves that it has ALWAYS been relatively 'easy' to filter any kind of data coming from Apache from within Apache itself and there really wasn't much need for an EAPI interface in the first place. The mod_ssl folks just thought there was. mod_gzip actually shows how easily the filtering can be done in several different ways and on serveral different levels. The very first version of mod_gzip ( December, 2000 ) did nothing more than add a 'gather buffer' onto the same code that executes CGI programs and that worked for just about all external CGI ( Perl, Python, ColdFusion, etc ). The internal streams coming from other modules that were actually part of Apache were another story and the second version ( January, 2001 ) added a little more 'smarts' to the same 'gather buffer' approach. The latest version ( 1.3.19.1a ) was released a few days after Apache 1.3.19 was released so it could be tested against the latest release of Apache and it actually uses an entirely 'new' approach that works fine for both internal/external data streams and/or static/dynamic content. It's a significant improvement over the 'gather buffer' approach but it's interesting to note that both approaches actually work AOK. >According to its documentation, >it manipulates not only static files, but also the output of other >modules. It comes as one C file (Apache module), without patching >anything else. > >I'd appreciate if there are answers for my humble questions: > >1. Am I wrong? Or the "trick" was finally found? You are not wrong... and it's not really a 'trick'. It simply uses standard Apache API calls and it works all the way back to Apache 1.3.1 and even farther than that if you are willing to simply compile it into the core. The only real limitation on the code as far as Apache version numbers go is that the current release ( 1.3.19.1a ) makes use of the ap_regexec() regular expression call to help 'filter' the request and response headers. Apache didn't add the 'ap_regexec' stuff until around 1.3.6 so if you want to use mod_gzip with something that pre-dates the addition of the regular expression calls you simply must comment out the references. >2. Can this trick be used for other purposes? (such as SSL; Such a trick > may be used to avoid the EAPI patches which are inserted into the > core source of Apache) mod_gzip can compress the output of mod_ssl just fine. It does it before SSL performs the encryption. I believe Tim Frank was the first to use mod_gzip to compress his SSL output and Henri Gomez has posted a message to the forum just today describing how he does it. There are actually a number of ways to 'do it'. I have a 'test' version of mod_gzip here that simply has it's own calls to the OpenSSL libraries in it and it produces the same result as using mod_gzip and mod_ssl together... but doesn't even require mod_ssl and doesn't even require Apache to be re-compiled. >3. Does mod_gzip and mod_ssl (the current) run together? Or is there > any conflict? No conflicts at all. >4. Is there any cost for this trick? (i.e. is EAPI/etc. more efficient?) Define cost? The answer to that one is going to be pretty subjective, I'm afraid. It has always been a good idea to provide a 'connection level hook' in Apache ( which is what EAPI provides ) and it should be added to the standard code base so that you don't need the EAPI stuff to get it... but whether this connection level 'hook' is really necessary to do certain things or not is arguable. >5. Can your trick be used to manipulate the input (a.k.a. HTTP requests) > and headers too? Yes. >6. Is there any conflict with mod_proxy? No. > Can mod_gzip run together with > mod_proxy? Does it gzip its output too? Yes. Matter of fact... that's one way to compress SSL. You simply set up a Virtual Host that is SSL and use mod_proxy to funnel the requests to/from the 'virtual' server and mod_gzip takes care of the compression phase. Works great. See message from Henri Gomez. > (so you may add a reverse > proxy to an existing web server, without touching it, but only > speeding the output by compressing it externally) Yep... but you really don't even need the 'reverse proxy' to do that simple operation. The data that is 'leaving' Apache itself can already be compressed. > BTW: mod_proxy has been always HTTP/1.0 which is not supported by > gzip, but recently ported to support 1.1 as well. I don't know what you mean by 'HTTP/1.0 is not supported by gzip'. GZIP doesn't care and HTTP/1.0 doesn't either, really. As a matter of fact... there are MANY versions of major browsers that are only HTTP/1.0 compliant yet they will always send the 'Accept-encoding: gzip' request header and if the server returns IETF Content-encoding it works just fine. Both Netscape 4.x and MSIE 4.x browsers do this. You can argue that it is a total violation of protocol to send HTTP/1.1 header fields in an HTTP/1.0 reuquest ( and you would be right ) but that doesn't really matter. What matters is that it WORKS. Yours... Kevin Kiley >Thanks in advance, >Eli Marmor >[EMAIL PROTECTED] >CTO, Founder >Netmask (El-Mar) Internet Technologies Ltd. >__________________________________________________________ >Tel.: +972-9-766-1020 8 Yad-Harutzim St. >Fax.: +972-9-766-1314 P.O.B. 7004 >Mobile: +972-50-23-7338 Kfar-Saba 44641, Israel >_______________________________________________ >mod_gzip mailing list >[EMAIL PROTECTED] >http://lists.over.net/mailman/listinfo/mod_gzip ______________________________________________________________________ Apache Interface to OpenSSL (mod_ssl) www.modssl.org User Support Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
