[PATCH] Http gunzip: additional configuration

[Alon Blayer-Gat]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20170122/863db42e/attachment.html>