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