Aborting a filter.

[Nick Kew <ni...@webthing.com>]

I have a problem with mod_deflate's inflate filter (the one I wrote a
couple of months ago).  I've found a site that (repeatably) provides
compressed data that causes zlib to return -3 (data error). I hope I can
solve it by more detailed study of zlib, but it raises a broader issue.

The inflate-filter is error-handling in what seems an appropriate manner -
aborting the decompress and returning APR_EGENERAL.  But that then
propagates NOBODY_WROTE, and the client is getting unexpected end
of connection, which is not good.

The cop-out of a remove_output_filter and a pass_brigade is no use here,
as the error could be mid-stream, and the Content-Encoding header has
already been stripped in any case.

Instinctively I'd like to see the Client get a 500 errordoc in such cases.
But that's not an option mid-stream either.  OTOH, if it happens before
core_output_filter has got any data, is there any cleanup core can do
about this to improve the client experience?

Any thoughts?  Has this been discussed before?

-- 
Nick Kew

RE: Aborting a filter.

[Nick Kew <ni...@webthing.com>]

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>?

-- 
Nick Kew

RE: Aborting a filter.

["Peter J. Cranstone" <cr...@msn.com>]

Thanks... we're currently testing a new version of mod_gzip called
mod_gzip64i

It's specifically coded for Itanium at the moment - but we're seeing between
factor 2 - factor 3 performance improvement (you can now buy a single cpu
Itanium for less than $3500) and Apache runs just fine on it. (about 20% -
30% faster for a 1Ghz Itanium vs. a Pentium 2.4Ghz)

I'll check out the site and see if we have any problems.

Thanks,


Peter 

-----Original Message-----
From: Nick Kew [mailto:nick@webthing.com] 
Sent: Monday, June 21, 2004 11:17 PM
To: dev@httpd.apache.org
Subject: RE: Aborting a filter.

On Mon, 21 Jun 2004, Peter J. Cranstone wrote:

> Can you provide the name of the site?

www.dn.se

(one of a list of several hundred test sites used by my Client).

It's a slightly-dated Apache + mod_gzip, and if I capture the data,
gzip itself can uncompress it.

-- 
Nick Kew

RE: Aborting a filter.

[Nick Kew <ni...@webthing.com>]

On Mon, 21 Jun 2004, Peter J. Cranstone wrote:

> Can you provide the name of the site?

www.dn.se

(one of a list of several hundred test sites used by my Client).

It's a slightly-dated Apache + mod_gzip, and if I capture the data,
gzip itself can uncompress it.

-- 
Nick Kew

RE: Aborting a filter.

["Peter J. Cranstone" <cr...@msn.com>]

Can you provide the name of the site?

Thanks,

Peter

-----Original Message-----
From: Nick Kew [mailto:nick@webthing.com] 
Sent: Monday, June 21, 2004 8:53 AM
To: apache-modules@covalent.net; dev@httpd.apache.org
Subject: Aborting a filter.


I have a problem with mod_deflate's inflate filter (the one I wrote a
couple of months ago).  I've found a site that (repeatably) provides
compressed data that causes zlib to return -3 (data error). I hope I can
solve it by more detailed study of zlib, but it raises a broader issue.

The inflate-filter is error-handling in what seems an appropriate manner -
aborting the decompress and returning APR_EGENERAL.  But that then
propagates NOBODY_WROTE, and the client is getting unexpected end
of connection, which is not good.

The cop-out of a remove_output_filter and a pass_brigade is no use here,
as the error could be mid-stream, and the Content-Encoding header has
already been stripped in any case.

Instinctively I'd like to see the Client get a 500 errordoc in such cases.
But that's not an option mid-stream either.  OTOH, if it happens before
core_output_filter has got any data, is there any cleanup core can do
about this to improve the client experience?

Any thoughts?  Has this been discussed before?

-- 
Nick Kew