The worst evil in Nginx is if when used in location context. Much has been written about this, including posts on nginx.com. Let’s take a quote:

The only 100% safe things which may be done inside if in a location context are:

- return ...;

- rewrite ... last;

It seems that nothing terrible will happen if you use a construction like

location / {
  if ($condition) {
    return 418;
  }
  ...
}

However, with a certain “skill”, you can even break something that is 100% safe. But will if be responsible for this malfunction?

Let’s assume we have a web server that accepts POST requests:

server {
    root /www/example_com;
    listen *:80;
    server_name .example.com;
        
    location /index.php {
        fastcgi_pass   unix:/var/run/php-fpm.sock;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include        fastcgi_params;
    }
}

$ cat /www/example_com/index.php
<?php
var_dump($_REQUEST);
?>

$ curl \
> -w "HTTP CODE: %{http_code}\n" \
> -d "key1=value1" \
> -X POST \
> "example.com/index.php" \
> 
array(1) {
  ["key1"]=>
  string(6) "value1"
}
HTTP CODE: 200

At some point, we want to filter out requests with empty bodies. The first thing we can think of makes the config look like this:

server {
  root /www/example_com;
  listen *:80;
  server_name  .example.com;
        
  location /index.php {
    fastcgi_pass unix:/var/run/php-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;

    if ($request_body = '') {
      return 418;
    }
  }
}

However, this idea is a mistake. The fact is that in this configuration, we will always (no matter the body is sent or not) get the 418th response:

$ curl \
> -w "HTTP CODE: %{http_code}\n" \
> -X POST \
> "example.com/index.php" \
> 
HTTP CODE: 418

$ curl \
> -w "HTTP CODE: %{http_code}\n" \
> -d "key1=value1" \
> -X POST \
> "example.com/index.php" \
> 
HTTP CODE: 418

How phases are defined in Nginx:

typedef enum {
    NGX_HTTP_POST_READ_PHASE = 0,
    NGX_HTTP_SERVER_REWRITE_PHASE,
    NGX_HTTP_FIND_CONFIG_PHASE,
    NGX_HTTP_REWRITE_PHASE,
    NGX_HTTP_POST_REWRITE_PHASE,
    NGX_HTTP_PREACCESS_PHASE,
    NGX_HTTP_ACCESS_PHASE,
    NGX_HTTP_POST_ACCESS_PHASE,
    NGX_HTTP_PRECONTENT_PHASE,
    NGX_HTTP_CONTENT_PHASE,
    NGX_HTTP_LOG_PHASE
} ngx_http_phases;

Our condition uses the variable $request_body, whose value appears in locations processed by proxy_pass, fastcgi_pass, uwsgi_pass, and scgi_pass directives when the body is read into an in-memory buffer.

Therefore, the value of the variable is set in the NGX_HTTP_CONTENT_PHASE phase, while the if directive of the ngx_http_rewrite_module module is executed in the NGX_HTTP_REWRITE_PHASE phase. That is, at the moment of checking the condition, the $request_body variable will not be assigned any value regardless of whether the body is empty or not. Therefore, any queries will be responded to with"418 I’m a teapot".

Thus, although the 100% efficient version is no longer working, if in location context has nothing to do with it. This is only about the order of request processing phases.