httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter J. Cranstone" <>
Subject RE: Apache license and GZIP
Date Thu, 14 Oct 1999 20:49:56 GMT
Wilfredo Sanchez wrote:

> Heh.  This isn't the lottery.

Not quite sure what that comment is all about. What we are trying to do here
is see how we can release our code with Apache. I don't care if you don't
want to go faster, however last time I checked bandwidth is not free.

> Zlib is not under the GPL's terms.  The Zlib copyright is quite
reasonable.  I don't think that's an issue.

Why don't you think it's an issue. Zlib is under the GNU public license,
Apache has it's own APL license, they are both different. The question is
can we release GNU public code inside Apache? (Note this debate has been
discussed before on this forum with many different opinions)

Here is the problem. Forking servers do not take well to compression threads
being spawned alongside there own threads. Everyone ends up fighting for
resources and if the compression cycles have not been completed CPU
utilization falls to zero. That's why we've had to build an application
which does not rely on forking for compression and in addition build it so
if does not impact Apache's own resource requirements. That's why it's an
external application and not simply buried in the Apache source code as a
module. If we could build a mod_compression that handled content and
transfer encoding and simply shelled to gzip on the fly the problem would be
solved. The only problem then would be that the server would roll over die
due to lack of resources. A simple test. Try forking 300 copies of Apache
and asking each fork to compress on the fly. On a busy server capable of
handling 1000's of hits a second compression is not an option unless it's an
external application which does not need to fork each request.

Why use gzip and not simply some other public domain compression algorithm
(if you can find one which is not under GNU)?

Gzip is already on most Unix servers, and it's supported by most of the
browsers (95% of the market) (in a separate .DLL to get around the GNU
issue.) If you don't use gzip then you have to write a client piece which is
supported by all the browsers. And you still haven't solved the server


Peter J. Cranstone

-----Original Message-----
From: []On
Behalf Of Wilfredo Sanchez
Sent: Thursday, October 14, 1999 2:03 PM
Subject: Re: Apache license and GZIP

| Who said there wasn't still a chance it could all be yours for the

Heh.  This isn't the lottery.

| 1. Is there anything stopping a series of patches that contain
| a highly, highly optimized version of the GNU based ZLIB/GZIP
| code from actually being included in a source release of Apache?

  Zlib is not under the GPL's terms.  The Zlib copyright is quite
reasonable.  I don't think that's an issue.

  Item #2 is therefore moot.

| 3. Based on 1 and 2... Is it even possible to proceed here?

  Yes. A patch file is the next step.

| 4. I have my own version of ApacheBench that already has full
| RFC compliant support for both Content-encoding and Transfer-encoding
| in it. Apache's ability to send both at the same time is totally broken
| but at least you can Bench one or the other. Any takers?
| Unless someone says 'Yes we want that'... it will not be sent.
| I won't waste your time or mine. You can read about compressed
| content in the newspapers sometime down the road.

  Can't tell you whether we want it if we haven't seen it.  Send the
code, or a URL to it.

  Quit with the stupid "read about it later" crap.  You said that
already.  We get it.


       Wilfredo Sanchez,
Apple Computer, Inc., Core Operating Systems / BSD
          Technical Lead, Darwin Project
   1 Infinite Loop, 302-4K, Cupertino, CA 95014

View raw message