A patch to force the gunzip filter module work

Maxim Dounin mdounin at mdounin.ru
Thu Jan 24 11:23:18 UTC 2013


Hello!

On Thu, Jan 24, 2013 at 06:47:03PM +0800, 姚伟斌 wrote:

> Thanks, Maxim. I know what you means. But there may be some problems with
> the order of filter modules. If a filter module's header filter function
> sets the filter_need_in_memory flag, it should be run before the gunzip
> module. And this filter module indeed need parse the response after the
> gunzip module in the body filter function. This may be a problem?

Yes, as some headers have to be modified by gunzip - and this in 
turn should happen before (at least some of) other filters.  This 
needs detailsed investigation, probably aproach similar to range 
filter will work here (i.e. separate header and body filters).

> 
> 2013/1/24 Maxim Dounin <mdounin at mdounin.ru>
> 
> > Hello!
> >
> > On Wed, Jan 23, 2013 at 11:46:56AM +0800, 姚伟斌 wrote:
> >
> > > Hi,
> > >
> > > I have used the gunzip filter module to inflate the compressed response.
> > > This module is very efficient and help us a lot. But it It just work when
> > > the request don't send the Accept-Encoding: Gzip header. If the client
> > can
> > > accept compressed response, it will not work at all. I have changed this
> > > module and added a gunzip_force directive. Then it will always inflate
> > the
> > > compressed response when the directive is turned on.
> > >
> > > This patch could be helpful for other filter modules, like ssi module and
> > > substitute module etc. It can save the bandwidth with backend servers. In
> > > our company, the intranet bandwidth really kills us.
> > >
> > > This patch is from the separated gunzip module. It should be similar with
> > > the Nginx official source code. Hope this be helpful.
> >
> > You probably seen this comment at the top of gunzip handler:
> >
> >     /* TODO always gunzip - due to configuration or module request */
> >
> > While configuration directive certainly will work, but it looks
> > like a hack (and that's why it wasn't implemented).  I tend to
> > think it would be much better to make things just happen
> > automatically on module request, much like it's currently done
> > with reading response body into memory once
> > r->filter_need_in_memory is set by any filter.
> >
> > --
> > Maxim Dounin
> > http://nginx.com/support.html
> >
> > _______________________________________________
> > nginx-devel mailing list
> > nginx-devel at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> 
> 
> 
> 
> -- 
> Weibin Yao
> Developer @ Server Platform Team of Taobao

> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel


-- 
Maxim Dounin
http://nginx.com/support.html



More information about the nginx-devel mailing list