mod_include strangeness

[Allan Edwards <ak...@us.ibm.com>]

Seems that mod_include can pass empty bucket brigades
down the filter chain. For instance if the first line in
an SSI is  <!--#include... then SPLIT_AND_PASS_PRETAG_BUCKETS
will pass an empty brigade as the first brigade.

This causes problems with the logic in mod_deflate which
attempts to bypass deflate when a response has zero
body length (e.g. proxied 304's)

What happens is that this empty brigade gets passed down
the filter chain and ap_http_header_filter is called before
the Content-Encoding header has been set (mod_deflate is
holding off setting this until it knows it has some
content).

As a defensive move, mod_deflate could just check for
APR_BRIGADE_EMPTY and immediately return APR_SUCCESS.
Or we could put checks in mod_include to prevent passing
empty buckets in the first place (I think there was such
a check at one time but were taken out for performance
improving reasons?).

The latter might avoid problems with other modules
but being defensive is probably a good idea also.

Comments?

Allan

Re: mod_include strangeness

[Allan Edwards <ak...@us.ibm.com>]

Justin Erenkrantz wrote:
> You should really take a look at the trunk.  =)
> 
> This has been fixed for many months.  -- justin

Ah, I see it now! Thanks for the quick feedback Justin.

Allan

Re: mod_include strangeness

[Justin Erenkrantz <ju...@erenkrantz.com>]

--On Wednesday, December 1, 2004 6:44 PM -0500 Allan Edwards 
<ak...@us.ibm.com> wrote:

> As a defensive move, mod_deflate could just check for
> APR_BRIGADE_EMPTY and immediately return APR_SUCCESS.
> Or we could put checks in mod_include to prevent passing
> empty buckets in the first place (I think there was such
> a check at one time but were taken out for performance
> improving reasons?).

You should really take a look at the trunk.  =)

This has been fixed for many months.  -- justin