Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v753.1)
References: <9FA0728B-3DD5-4289-9235-D53A8666ABA5@webthing.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <4757F9AD-941E-4F03-9B61-FD80349F7888@apache.org>
Content-Transfer-Encoding: 7bit
From: Nick Kew <niq@apache.org>
Subject: Fwd: mod_deflate feature needed
Date: Thu, 16 Jul 2009 17:46:16 +0100
To: modules-dev@httpd.apache.org

Looks like this got lost in the ether ...

Begin forwarded message:
>
>
> On 15 Jul 2009, at 23:39, Anthony J. Biacco wrote:
>
>> I'm trying to use mod_deflate to compress data coming out of tomcat
>> through mod_jk and need the proper content-length header set for the
>> COMPRESSED data, but can't do this because the data is streamed  
>> and sent
>> after the headers are set, therefore we don't know the compressed
>> content-length until after the fact.
>> I'd either like to request a option to enable such a feature where  
>> I can
>> have the compressed data buffered, the headers set, and then the data
>> sent.
>
> That's the wrong approach.  Think modular!
>
> The right approach is to insert another filter after mod_deflate
> to do your buffering (and of course note its effect on performance
> and potential role in a DoS attack).  The existing content_length
> filter would make a startingpoint.
>
> Or, better, fix your client to support HTTP, without the need for
> a Content-Length header.
>
> -- 
> Nick Kew