Hi All,
I think Sander sum it up nicely.
- It is part of the spec. Apache should implement the spec.
- Almost all new browsers support IETF content encoding/transfer
encoding. In testing with MSIE 6.x and Netscape 6.1
compression works fine.
- The biggest users of mod_gzip are outside the USA. Why? Because
they pay for bandwidth.
- There are some "large" institutions (financial markets) that use
mod_gzip to reduce HTML/JavaScript etc.
- It supports dynamic and static content.
- You can compress SSL (with some hacks)
A couple of other issues.
- Netware. With a little help this can be fixed. However the
majority of the net runs either Apache, IIS, iPlanet or Zeus.
- Apache 2.x is not yet stable for all platforms.
- Debug code and size of mod_gzip... We can remove the debug code.
It's stable enough now after 9 months of solid testing to pull it.
In closing... Here is the biggest reason to include mod_gzip
-- compression (transfer encoding/content encoding) part of the HTTP
spec! --
<for those who hate long emails you can stop reading here>
<soap box>
Apache's market share dropped last month. Micro$oft IIS 5.0 is making
headway and "IT INCLUDES AN ISAPI GZ FILTER". It happens to be a pig and
it does not support compressed POST transactions (mod_gzip does) and it
has issues compressing Javascript. But bottom line, Microsoft is
supporting the standard and even though the first pass is rough it will
get better. Which means that if people figure out what European users
have been saying for nearly a year that compressing HTML etc really
makes a difference then Apache needs to embrace the light. Mod_gzip was
released with an Apache style license with this thought in mind. The
writing is on the wall, if Micro$oft sees a benefit to adding
compression then it's only a matter of time before everyone is demanding
it be there. My thought is that it would be better for Apache to be
first rather than playing catch up.
On a personal note. Kevin and I have been on this forum long enough to
know what the rules are. We released mod_gzip under an Apache style
license for one reason. So Apache would benefit. Sure Kevin is the
author and has continued to do an incredible job supporting the code,
but now others have joined the mod_gzip forum and have taken up the
challenge. On October 13th 2001 it will have been a year since the code
came out. It has not undergone any changes since March 2001 and is now
considered stable for Apache 1.3.x users. The 2.x version is only
waiting for one thing which is *beta*. What the server is stable enough
to run for months and users are upgrading to the new version we will
release mod_gzip for 2.x under exactly the same license as 1.x version.
<end>
Regards
Peter
-----Original Message-----
From: Sander Striker [mailto:[EMAIL PROTECTED]]
Sent: Sunday, September 02, 2001 6:12 AM
To: [EMAIL PROTECTED]
Subject: RE: [PATCH] Add mod_gz to httpd-2.0
Hi,
>From what I have seen on the list I am on the +1 side of
adding mod_gz(ip) to the distribution. Ofcourse, my vote doesn't count
since I don't have httpd commit.
I find the following arguments convincing (summarized):
- The gzip content encoding is part of the HTTP spec.
- Most clients support gzip transfer coding.
- It is a real solution to the problem of network bandwidth
being the limiting factor on many heavily-loaded web servers
and on thin-piped clients.
- It makes the compression transparent to the admin of the
site and allows for dynamically generated content (which
can grow quite large) to be compressed aswell.
I haven't seen anything that held on the negative side yet.
Sander
