httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Anthony J. Biacco" <abia...@formatdynamics.com>
Subject RE: mod_deflate feature needed
Date Thu, 16 Jul 2009 17:26:10 GMT
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
abiacco@formatdynamics.com
http://www.formatdynamics.com


> -----Original Message-----
> From: Nick Kew [mailto:niq@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


Mime
View raw message