Welcome! Log In Create A New Profile

Advanced

Re: [PATCH] Http gunzip: additional configuration

Alon Blayer-Gat
January 23, 2017 01:24AM
Patch attached

On Sun, Jan 22, 2017 at 4:07 PM Alon Blayer-Gat <alon.blayergat@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@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@nginx.org
> > http://mailman.nginx.org/mailman/listinfo/nginx-devel
> >
> _______________________________________________
> nginx-devel mailing list
> nginx-devel@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
Subject Author Views Posted

[PATCH] Http gunzip: additional configuration

Alon Blayer-Gat 1171 November 27, 2016 07:30AM

Re: [PATCH] Http gunzip: additional configuration

Maxim Dounin 513 December 07, 2016 11:00AM

Re: [PATCH] Http gunzip: additional configuration

Alon Blayer-Gat 291 January 22, 2017 09:08AM

Re: [PATCH] Http gunzip: additional configuration

Alon Blayer-Gat 333 January 23, 2017 01:24AM

Re: [PATCH] Http gunzip: additional configuration

Maxim Dounin 612 January 26, 2017 09:02AM



Sorry, you do not have permission to post/reply in this forum.

Online Users

Guests: 175
Record Number of Users: 8 on April 13, 2023
Record Number of Guests: 421 on December 02, 2018
Powered by nginx      Powered by FreeBSD      PHP Powered      Powered by MariaDB      ipv6 ready