<div dir="ltr">Sure. Thanks for the feedback. I made is simpler.<br class="gmail_msg">evil 'if in location' removed :). I also removed the 'gunzip types;' option.<br class="gmail_msg">And now we now only have 'gunzip off|on|always'<br class="gmail_msg"><br class="gmail_msg">But then again, with 'always', one must specify with 'gunzip_types' the<br class="gmail_msg">mime types to always gunzip.<div>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.<br></div><div>Default mime type is text/html ( similar to gzip_types).<br><br>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.<br>This patch suggests a simple change for the benefit of existing text-related body-filter modules.<br><br>Hope it makes sense.<br class="gmail_msg">Patch attached.<br class="gmail_msg"><br>Thanks,<br class="gmail_msg">/Alon<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg">On Wed, Dec 7, 2016 at 5:58 PM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru" class="gmail_msg" target="_blank">mdounin@mdounin.ru</a>> wrote:<br class="gmail_msg"><br class="gmail_msg">> Hello!<br class="gmail_msg">><br class="gmail_msg">> On Sun, Nov 27, 2016 at 02:27:56PM +0200, Alon Blayer-Gat wrote:<br class="gmail_msg">><br class="gmail_msg">> > Hi,<br class="gmail_msg">> ><br class="gmail_msg">> > 1) 'gunzip always' option will gunzip even if the client supports it.<br class="gmail_msg">> > 2) 'gunzip types', like 'always' but only for file types specified<br class="gmail_msg">> > with 'gunzip_types <mime-types>'<br class="gmail_msg">> > 3) Allow gunzip and gunzip_types directives within "if in location"<br class="gmail_msg">> > block (rewrite phase condition).<br class="gmail_msg">> ><br class="gmail_msg">> > The suggested changes are needed, mainly, to allow dynamic<br class="gmail_msg">> > modification of compressed response (e.g. with the 'sub_filter'<br class="gmail_msg">> > module)<br class="gmail_msg">> > 'types' and 'if in location' may allow a more selective operation.<br class="gmail_msg">><br class="gmail_msg">> No, thanks.<br class="gmail_msg">><br class="gmail_msg">> "If in location" is evil, don't even try to suggest patches to<br class="gmail_msg">> allow directives in the "if in location" context.<br class="gmail_msg">><br class="gmail_msg">> As for other changes - I can't say I like them as well.  We may<br class="gmail_msg">> consider something as simple as "gunzip always", but additional<br class="gmail_msg">> types filter certainly looks like an overkill.  Rather it should<br class="gmail_msg">> be some more generic mechanism to require gunzipping, may be<br class="gmail_msg">> useable by modules directly.<br class="gmail_msg">><br class="gmail_msg">> [...]<br class="gmail_msg">><br class="gmail_msg">> --<br class="gmail_msg">> Maxim Dounin<br class="gmail_msg">><span class="inbox-inbox-Apple-converted-space"> </span><a href="http://nginx.org/" rel="noreferrer" class="gmail_msg" target="_blank">http://nginx.org/</a><br class="gmail_msg">> _______________________________________________<br class="gmail_msg">> nginx-devel mailing list<br class="gmail_msg">><span class="inbox-inbox-Apple-converted-space"> </span><a href="mailto:nginx-devel@nginx.org" class="gmail_msg" target="_blank">nginx-devel@nginx.org</a><br class="gmail_msg">><span class="inbox-inbox-Apple-converted-space"> </span><a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" class="gmail_msg" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br class="gmail_msg">><br></div></div>