On Tue, 4 Jun 2002, Slava Bizyayev wrote:
> Dear Valerio, Alvar, and Igor,
> Thank you very much for your attention to Apache::Dynagzip.
> It is on CPAN now:
>
> The uploaded file Apache-Dynagzip-0.04.tar.gz has entered CPAN as
> file: $CPAN/authors/id/S/SL/SLAVA/Apache-Dynagzip-0.04.tar.gz
> size: 24939 bytes
> md5: 586610ffdd35cd1ceceaba4796fd6212
>
> I've just fixed a few typos and updated README for this version.
> Now I'm back in our discussion.
>
> I believe the questions, which we began to discuss yesterday with Valerio
> privately should go public being helpful for others too. Especially, seeing
> that they are similar to Alvar's interests.
>
> I feel this discussion very important, but this time it is not about the
> Dynagzip itself. Indeed, it is about the implementation of gzip compression
> in most common view.
>
> You know, there are 6 open source modules/packages for the web content
> compression available in the World (in alphabetic order):
>
> ·Apache::Compress
> ·Apache::Dynagzip
> ·Apache::Gzip
> ·Apache::GzipChain
> ·mod_deflate
I should note that there are two unrelated mod_deflate modules - my one for
Apache 1.3 and Apache2's one.
> ·mod_gzip
> On other hand, you know of-course, that the compression is used rarely in
> practice to date. My own observations show that there are only few content
> providers, who compress their traffic. I would mention Oracle as the leader,
> which covers a significant percent of its on-line documentation with gzip
> compression (looks like a static approach). On Yahoo there are few pages
> gzipped only. Even the US governmental sites do not use gzip. Why?
>
> Because it is not that simple to implement the web compression to date. The
> success of the compression implementation depends on quality of client side
> software. I would not consider the efforts of browser vendors sufficient
> these days. We know many bugs. Others are still hidden. We can't fix them.
> To adjust a web server appropriately is a common problem for any of
> mentioned compression modules.
mod_deflate had been used for one year on several popular Russian sites
without problems so I think the main browsers have good gzip support.
> That's why I believe it is better to have one simple common rule in all
> compression modules (like an Accept-Encoding header), and a flexible FixUp
> handler, which should control the $r->header_in('Accept-Encoding') prior to
> compression handler.
Fixup handler is too early for this.
> I don't know should it be a kitchen of every system administrator, or
> somebody could volunteer to serve the public web site about the current
> conditions of different web clients and recommended masks?.. I can't host it
> on my devl4, because it is a development machine. That would be better to
> find some stable place, like mod_perl, or apache project ;-).
I can host it on my site. I already have list of browser gzip/deflate
capabilites and bugs in mod_deflate Russian documentation.
I need simply translate it to English.
Igor Sysoev
http://sysoev.ru
