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
·mod_gzip
And (I guess) many specific commercial modules were written around. These
days even Microsoft has own gzip DLL for IIS.
You know advantages of the web content compression. It's easy to explain to
any executive how good it is for him to compress his web traffic.
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.
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.
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 ;-).
Any suggestions?
Thanks,
Slava
