Re: svn commit: r1146418 - in /httpd/httpd/trunk: CHANGES modules/filters/mod_deflate.c

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

On 13 Jul 2011, at 21:38, sf@apache.org wrote:

> Author: sf
> Date: Wed Jul 13 20:38:33 2011
> New Revision: 1146418
> 
> URL: http://svn.apache.org/viewvc?rev=1146418&view=rev
> Log:
> Don't try to compress requests with a zero sized body.
> 
> PR: 51350

PR 51590 tells us this introduces a new spinning bug.

Investigating that reveals what looks like a deeper problem:

> +            rc = apr_bucket_read(e, &data, &len, APR_BLOCK_READ);

Depending on the bucket type, this read might be discarding vital data!
Or am I missing something?

-- 
Nick Kew

Available for work, contract or permanent
http://www.webthing.com/~nick/cv.html

Re: svn commit: r1146418 - in /httpd/httpd/trunk: CHANGES modules/filters/mod_deflate.c

[Stefan Fritsch <sf...@sfritsch.de>]

On Saturday 30 July 2011, Nick Kew wrote:
> On 13 Jul 2011, at 21:38, sf@apache.org wrote:
> > Author: sf
> > Date: Wed Jul 13 20:38:33 2011
> > New Revision: 1146418
> > 
> > URL: http://svn.apache.org/viewvc?rev=1146418&view=rev
> > Log:
> > Don't try to compress requests with a zero sized body.
> > 
> > PR: 51350
> 
> PR 51590 tells us this introduces a new spinning bug.
> 
> Investigating that reveals what looks like a deeper problem:
> > +            rc = apr_bucket_read(e, &data, &len,
> > APR_BLOCK_READ);
> 
> Depending on the bucket type, this read might be discarding vital
> data! Or am I missing something?

AFAIK, apr_bucket_read() should only convert buckets of undetermined 
length into buckets of actual data. But as long as the bucket is not 
removed from the brigade, no data should be lost. The 
apr_bucket_read() is not executed for metadata buckets.

The exact same apr_bucket_read() call is made again later. This 
shouldn't make any difference, should it? I think Torsten's patch is 
correct. And the modules/deflate.t tests do compare undeflated and 
deflated output. So they should catch lost data.