Request Processing Phases in Nginx. Is if Evil?

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.