Problem in mod_deflate

[Torsten Förtsch <to...@gmx.net>]

Hi,

the DEFLATE output filter contains this piece of code (as of server magic
number 20110724)

    if (!ctx) {
        char *token;
        const char *encoding;

        /* Delay initialization until we have seen some data */
        e = APR_BRIGADE_FIRST(bb);
        while (1) {
            apr_status_t rc;
            if (e == APR_BRIGADE_SENTINEL(bb))
                return ap_pass_brigade(f->next, bb);
            if (APR_BUCKET_IS_EOS(e)) {
                ap_remove_output_filter(f);
                return ap_pass_brigade(f->next, bb);
            }
            if (APR_BUCKET_IS_METADATA(e))
                continue;

If there is no filter context yet and the passed brigade contains only a
metadata bucket (a flush bucket for example) the "continue" statement is 
hit without changing "e". Hence, it enters an infinite loop.

The last "if" statement should read as follows to avoid the loop:

            if (APR_BUCKET_IS_METADATA(e)) {
                e = APR_BUCKET_NEXT(e);
                continue;
            }

Filed as https://issues.apache.org/bugzilla/show_bug.cgi?id=51590

Torsten Förtsch

-- 
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net

Re: Problem in mod_deflate

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

On Tuesday 02 August 2011, Torsten Förtsch wrote:
> I don't know how common this situation is. It came up in the
> modperl test suite (t/filter/both_str_req_mix.t). This test
> contructs a filter chain like
> 
>   modperl filter
> 
>   INCLUDES
> 
>   another modperl filter
> 
>   DEFLATE
> 
> The INCLUDES filter was passed a brigade containing a data bucket
> with single SSI command like "<!--#include virtual=... -->" and a
> flush bucket. mod_include then tries to find the "<!--#" sequence
> and splits the bucket before this string. Thus, it gets a bucket
> with an empty string. I am not sure if this bucket was delivered
> in a separate brigade to the DEFLATE filter and the flush bucket
> in the next one or if it was accompanied by the flush bucket.
> 
> Although I can think of usage cases where it is common to send a
> flush bucket in the first place just to get the headers out I
> can't think of a way to make this happen with core httpd modules.
> 
> So, I don't know if it qualifies for a showstopper for 2.3.14 beta.

Thanks for the detailed information. Since I also know no way to 
trigger this bug in normal setups, I think it should not be a blocker 
for beta. 

> BTW, I filed another simple bug
> https://issues.apache.org/bugzilla/show_bug.cgi?id=51592 which was
> also triggered by the modperl test suite. What are the chances for
> it to get applied?

Fixed. Thanks again.

Re: Problem in mod_deflate

[Torsten Förtsch <to...@gmx.net>]

Hi Stefan,

thanks for applying.

On Saturday, 30 July 2011 17:41:39 Torsten Förtsch wrote:
> The last "if" statement should read as follows to avoid the loop:
> 
>             if (APR_BUCKET_IS_METADATA(e)) {
>                 e = APR_BUCKET_NEXT(e);
>                 continue;
>             }

I don't know how common this situation is. It came up in the modperl test 
suite (t/filter/both_str_req_mix.t). This test contructs a filter chain 
like

  modperl filter
     |
  INCLUDES
     |
  another modperl filter
     |
  DEFLATE

The INCLUDES filter was passed a brigade containing a data bucket with 
single SSI command like "<!--#include virtual=... -->" and a flush 
bucket. mod_include then tries to find the "<!--#" sequence and splits 
the bucket before this string. Thus, it gets a bucket with an empty 
string. I am not sure if this bucket was delivered in a separate brigade
to the DEFLATE filter and the flush bucket in the next one or if it was 
accompanied by the flush bucket.

Although I can think of usage cases where it is common to send a flush 
bucket in the first place just to get the headers out I can't think of a 
way to make this happen with core httpd modules.

So, I don't know if it qualifies for a showstopper for 2.3.14 beta.

BTW, I filed another simple bug 
https://issues.apache.org/bugzilla/show_bug.cgi?id=51592 which was also 
triggered by the modperl test suite. What are the chances for it to get 
applied?

The rest of the failures of the modperl test suite are then bound to API 
changes in logging and aaa. I hope not to find any more core bugs there.

Torsten Förtsch

-- 
Need professional modperl support? Hire me! (http://foertsch.name)

Like fantasy? http://kabatinte.net