Thank you for the answer. A more generic question follows:

While we understand that IfIsEvil mostly applies to "being evil inside
location context."...

We notice some directives allow being placed within "if in location" but
not within "if" in the server context.

An example is gzip module's main directive:
http://nginx.org/en/docs/http/ngx_http_gzip_module.html#gzip

Context: http, server, location, if in location

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).

Is there a specific rationale for why many NGINX directives are not allowed
in server-level "if" but are allowed in "if in location"?

Consequentially, is there any problem in allowing server-level `if` context
for such directives by adding corresponding flags?
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?

Best regards,
Danila


On Sun, Nov 27, 2022 at 1:38 AM Maxim Dounin <mdounin@mdounin.ru> wrote:

> Hello!
>
> On Sun, Nov 27, 2022 at 01:01:54AM +0800, Danila Vershinin wrote:
>
> > Hi,
> >
> > For our purposes, we need to be able to turn off etag under specific
> > conditions, e.g.:
> >
> > location / {
> > if ($condition) {
> > etag off;
> > }
> > }
> >
> > However, this syntax is invalid because this directive doesn't include
> > the NGX_HTTP_LIF_CONF flag.
> >
> > We added that flag. Then recompiled NGINX. So now:
> >
> > * the syntax is accepted by NGINX
> > * at runtime it works as desired
> >
> > Are there any potential problems with this approach? Performance or
> > otherwise?
>
> The generic issue with the "if" directive within a location
> context is that it creates a separate configuration, and therefore
> works in a counter-intuitive way in many cases (including being
> counter-intuitive for developers, which results in various bugs),
> see IfIsEvil wiki article for the details. Due to this, no new
> directives are allowed to work in the if-in-location context.
>
> Other than that, it probably should work fine assuming it works
> for you now and you are ok to maintain the patch yourself.
>
> A more portable solution might be to use
>
> map $condition $etag {
> default $sent_http_etag;
> 1 "";
> }
>
> add_header ETag $etag;
>
> to conditionally remove the ETag header.
>
> --
> Maxim Dounin
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list -- nginx-devel@nginx.org
> To unsubscribe send an email to nginx-devel-leave@nginx.org
>
_______________________________________________
nginx-devel mailing list -- nginx-devel@nginx.org
To unsubscribe send an email to nginx-devel-leave@nginx.org