>On Tue, 22 Jun 2004, Peter J. Cranstone wrote:
>
>> Thanks... we're currently testing a new version of mod_gzip called
>> mod_gzip64i
>
> For the record, I've fixed the problem.
Super!
> It was a failure to support some of the compression flags.
> Now I'll have to (side?)port it into a CVS version of mod_deflate ...
Suggestion: 99 time out of 100 these kind of errors from ZLIB
are going to come right off the bat when the ZLIB stuff first
reads the LZ77 'header'. Any 'incompatibilites' will discovered
right then and there.
What you probably ought to do in your filter is make the FIRST
ZLIB call and check the return code and, if bad, not even
bother to compress. Just 'reject' it and shut down the filter
like you already do for other 'front door' reasons.
Once you start the compression and the filter is 'engaged'
and you have returned 'OK' it's too late to go back.
It would be VERY RARE to get past the initial header read
with ZLIB without an error and THEN run into a data error
somewhere in the middle of the compression. Whatever
error you might get would almost always be 'knowable'
at the point where you still have the chance to not even
do the compression at all and 'remove' the filter from
this particular response.
> [grumble] Why isn't this documented in the manpages or in zlib.h[/grumble]?
There is a LOT about ZLIB ( and GZIP, for that matter ) that isn't
documented anywhere. Welcome to the party.
Later...
Kevin
In a message dated 6/24/2004 6:05:09 AM Central Daylight Time, [EMAIL PROTECTED] writes:
On Tue, 22 Jun 2004, Peter J. Cranstone wrote:
> Thanks... we're currently testing a new version of mod_gzip called
> mod_gzip64i
For the record, I've fixed the problem. It was a failure to support
some of the compression flags. Now I'll have to (side?)port it into
a CVS version of mod_deflate ...
<grumble>Why isn't this documented in the manpages or in zlib.h</grumble>?
--
