<div dir="ltr">Thank you for the answer. A more generic question follows:<div><br></div><div>While we understand that IfIsEvil mostly applies to "being evil inside location context."...</div><div><br></div><div>We notice some directives allow being placed within "if in location" but not within "if" in the server context.</div><div><br></div><div>An example is gzip module's main directive:  <a href="http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip">http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip</a></div><div><br></div><div>Context:   http, server, location, if in location<br></div><div><br></div><div>So "gzip on" can be done in "if in location", but NGINX does not allow this to be done in just "if" (which seems not an "evil" thing to do).</div><div><br></div><div>Is there a specific rationale for why many NGINX directives are not allowed in server-level "if" but are allowed in "if in location"?</div><div><br></div><div>Consequentially, is there any problem in allowing server-level `if` context for such directives by adding corresponding flags?</div><div>And is there are problem in doing the same for directives that doesn't support any kind of "if" (neither `if` in server nor `if in location`), like `gzip_proxied` directive?</div><div><br></div><div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Best regards,<br>Danila</div></div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Nov 27, 2022 at 1:38 AM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Sun, Nov 27, 2022 at 01:01:54AM +0800, Danila Vershinin wrote:<br>
<br>
> Hi,<br>
> <br>
> For our purposes, we need to be able to turn off etag under specific<br>
> conditions, e.g.:<br>
> <br>
> location / {<br>
>     if ($condition) {<br>
>         etag off;<br>
>     }<br>
> }<br>
> <br>
> However, this syntax is invalid because this directive doesn't include<br>
> the NGX_HTTP_LIF_CONF flag.<br>
> <br>
> We added that flag. Then recompiled NGINX. So now:<br>
> <br>
> * the syntax is accepted by NGINX<br>
> * at runtime it works as desired<br>
> <br>
> Are there any potential problems with this approach? Performance or<br>
> otherwise?<br>
<br>
The generic issue with the "if" directive within a location <br>
context is that it creates a separate configuration, and therefore <br>
works in a counter-intuitive way in many cases (including being <br>
counter-intuitive for developers, which results in various bugs), <br>
see IfIsEvil wiki article for the details.  Due to this, no new <br>
directives are allowed to work in the if-in-location context.<br>
<br>
Other than that, it probably should work fine assuming it works <br>
for you now and you are ok to maintain the patch yourself.<br>
<br>
A more portable solution might be to use<br>
<br>
    map $condition $etag {<br>
        default    $sent_http_etag;<br>
        1          "";<br>
    }<br>
<br>
    add_header ETag $etag;<br>
<br>
to conditionally remove the ETag header.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-devel mailing list -- <a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
To unsubscribe send an email to <a href="mailto:nginx-devel-leave@nginx.org" target="_blank">nginx-devel-leave@nginx.org</a><br>
</blockquote></div>