[PATCH] Http gunzip: additional configuration

Alon Blayer-Gat alon.blayergat at gmail.com
Mon Jan 23 06:23:05 UTC 2017


Patch attached

On Sun, Jan 22, 2017 at 4:07 PM Alon Blayer-Gat <alon.blayergat at gmail.com>
wrote:

> Sure. Thanks for the feedback. I made is simpler.
>
> evil 'if in location' removed :). I also removed the 'gunzip types;'
> option.
> And now we now only have 'gunzip off|on|always'
>
> But then again, with 'always', one must specify with 'gunzip_types' the
> mime types to always gunzip.
> The rational is that if we want to always gunzip, then it's probably not
> because the client does not support it but rather because we would like to
> modify the response. In which case, it is needed only for specific content
> types.
> Default mime type is text/html ( similar to gzip_types).
>
> I thought of your suggestion of making a more generic mechanism to be used
> by modules directly. It would require modifications in existing modules to
> make the feature usable.
> This patch suggests a simple change for the benefit of existing
> text-related body-filter modules.
>
> Hope it makes sense.
> Patch attached.
>
> Thanks,
>
> /Alon
>
>
> On Wed, Dec 7, 2016 at 5:58 PM Maxim Dounin <mdounin at mdounin.ru> wrote:
>
> > Hello!
> >
> > On Sun, Nov 27, 2016 at 02:27:56PM +0200, Alon Blayer-Gat wrote:
> >
> > > Hi,
> > >
> > > 1) 'gunzip always' option will gunzip even if the client supports it.
> > > 2) 'gunzip types', like 'always' but only for file types specified
> > > with 'gunzip_types <mime-types>'
> > > 3) Allow gunzip and gunzip_types directives within "if in location"
> > > block (rewrite phase condition).
> > >
> > > The suggested changes are needed, mainly, to allow dynamic
> > > modification of compressed response (e.g. with the 'sub_filter'
> > > module)
> > > 'types' and 'if in location' may allow a more selective operation.
> >
> > No, thanks.
> >
> > "If in location" is evil, don't even try to suggest patches to
> > allow directives in the "if in location" context.
> >
> > As for other changes - I can't say I like them as well.  We may
> > consider something as simple as "gunzip always", but additional
> > types filter certainly looks like an overkill.  Rather it should
> > be some more generic mechanism to require gunzipping, may be
> > useable by modules directly.
> >
> > [...]
> >
> > --
> > Maxim Dounin
> > http://nginx.org/
> > _______________________________________________
> > nginx-devel mailing list
> > nginx-devel at nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> >
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20170123/49408417/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ngx_http_gunzip_filter_module.patch
Type: text/x-patch
Size: 4150 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20170123/49408417/attachment.bin>


More information about the nginx-devel mailing list