Justin Erenkrantz wrote:
> 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.
It should only compress html files.
the main reason for this is that some browsers (IE) can't handle compressed
Javascript and CSS files (that what the mod_gzip discussion boards say)
>
> (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...)
>
it does. GZ is a AP_FTYPE_HTTP_HEADER filter. mod_include is a content filter.
there is also a check to make sure that it is a 'main' request.
>
>>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.
>>
>
zlib (and berkley DB for that matter) provide functions for malloc/free
I looked at using pools, but I couldn't see how to pass the pool in.
so that zlib would be able to pass the right pool through.
if someone has some good ideas I'll patch the berkley DB to do that as well.
> 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.
agreed
zlib is everywhere. we should treat it similiar to how openssl libraries
are treated. (for MSVC .. assume they are in srclib/, otherwise --with-z=)
>
> AIUI, zlibc is completely transparent to any application. -- justin
>
..Ian
