Yep, I think it got lost nick. I'd go along with the filter idea after deflate if it does what I need. Are you referring to mod_filter based directives such as FilterProvider/FilterProtocol?
The client/partner/vendor isn't requiring it to support HTTP, but to support their services. -Tony --------------------------- Manager, IT Operations Format Dynamics, Inc. 303-573-1800x27 abia...@formatdynamics.com http://www.formatdynamics.com > -----Original Message----- > From: Nick Kew [mailto:n...@apache.org] > Sent: Thursday, July 16, 2009 10:46 AM > To: modules-dev@httpd.apache.org > Subject: Fwd: mod_deflate feature needed > > 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
