Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Thu, 22 Jul 2004 11:52:42 +0100 (BST)
From: Nick Kew <nick@webthing.com>
To: dev@httpd.apache.org
Subject: Re: cvs commit: httpd-2.0/modules/filters mod_deflate.c
In-Reply-To: <20040719154152.GD22422@redhat.com>
Message-ID: <Pine.LNX.4.53.0407221139490.2344@hugin.webthing.com>
References: <20040717152235.62897.qmail@minotaur.apache.org>
 <20040719110655.GA22910@redhat.com>
 <Pine.LNX.4.53.0407191528370.21040@hugin.webthing.com>
 <20040719154152.GD22422@redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Mon, 19 Jul 2004, Joe Orton wrote:

> Nothing like that was posted to the list, at least.  Patch below is
> still sufficient to fix the proxy+304 case; does it work for you too?

Yes, mostly (it fixes the important bug that was previously a
showstopper).  And it's an improvement on my hack by virtue of
simplicity.

But it should still set the Content-Encoding header on a HEAD request
that would normally be deflated (and unset content-length if present).
So your:

+        /* Deflating a zero-length response would make it longer; the
+         * proxy may pass through an empty response for a 304 too. */
+        if (APR_BUCKET_IS_EOS(APR_BRIGADE_FIRST(bb))) {
+            ap_remove_output_filter(f);
+            return ap_pass_brigade(f->next, bb);
+        }
+

should move after the the
	if ( ! force-gzip )
block, and if then if we reach the EOS-only test we should fix up
the headers.

That test also seems to lose the pathological case of a brigade
with no data but one or more FLUSH buckets followed by EOS.
Could that ever happen in a HEAD or a 204/304?


Investigating this has revealed a similar bug with HEAD requests
in inflate_out_filter, which I shall now have to fix:-(


-- 
Nick Kew