On Sun, Sep 02, 2001 at 12:43:09PM -0500, William A. Rowe, Jr. wrote:
> > The gzip content encoding is part of the HTTP spec. 
> 
> By implementation, or reference?  Sure Content-encoding is part of the spec, and
> it's defined to allow authors to extend their support to any number of encodings,
> and forces the server to use only what the client claims as supported encodings.

gzip is mentioned explicitly in RFC 2616 as a supported content-encoding
(one registered with IANA).

> +1 with caviat to follow.

Cool.  BTW, do these +1 (concept) votes count towards mod_gz's 
inclusion?  I now count three binding +1 (concepts) for this (Cliff,
Greg, and OtherBill).  Or, do I need to wait until I receive two
+1s for mod_gz explicitly?

> So we need any gzip filter to drop out quick if 1. it knows this mime type should
> not be encoded; 2. it sees the content-encoding is already gz; 3. it sees the
> uri/filename whatever in a list of exclusions (that could be automagically grown
> when it hits files that _just_don't_compress_well_.

I would think that this is a httpd.conf configuration issue.  Remember,
we add mod_gz via:

AddOutputFilter GZ html

Ian's version did make sure that the content-type was text/html before
encoding.  But, I don't think that is necessary.  If the admin sets
mod_gz via the OutputFilter semantics, that's their wish (remember,
you must *ask* for mod_gz).  I'd rather not see these types of 
assumptions in any gzip module we implement.

(I need to double check that mod_gz and mod_include don't interfere
with each other...mod_gz should run *after* mod_include has processed
the data...)

> If we like, the entire zlib (168kb tar/gz'ed) could be distributed through /srclib/
> instead of by reference.  It really isn't that large, and matches what we do today
> with pcre and expat.  If we like, drop it into apr-util/encoding/unix/lib/zlib and
> only expose it through thunks (allowing someone to come up with more robust or faster
> apr-util thunks to source that we can _not_ redestribute.)  The more I contemplate,
> the stronger my +1 for apr-util remapping, where appropriate on some platforms.

Almost every platform I am aware of includes zlib by default now.
Solaris, AIX, Linux, FreeBSD.  Ian has all of the MSVC files (I didn't
post them as I want to place it in modules/filters which is different
than where Ian originally had it) - so I know he has something working
on Win32.  So, I don't think that we need to distribute zlib.  Nor do 
we need to perform "thunking."  It's just so common now.

AIUI, zlibc is completely transparent to any application.  -- justin

Reply via email to