limit_except VS $request_method !~ ^(GET|HEAD|POST)$

Question

I have been reading quite a bit about nginx lately and found 2 approaches online. The first appears to work at the server context level and the second is recommended for the location context level.

Question. Is it appropriate to use limit_except at the server context level?

Approach #1 ($request_method) embedded variable

# server context
#
# Disable unwanted HTTP methods
# Most of the time, you need just GET, HEAD & POST HTTP request in your web application.
# Allowing TRACE or DELETE is risky as it can allow Cross-Site Tracking attack and potentially
# allow an attacker to steal the cookie information.
# So we return a 405 Not Allowed if someone is trying to use TRACE, DELETE, PUT, OPTIONS.

if ($request_method !~ ^(GET|HEAD|POST)$ ) {

  return 405;

}

Approach #2 (limit_except) method

# Limits allowed HTTP methods inside a location.
. . .

location /restricted-write {

    # location context

    limit_except GET HEAD {

        # limit_except context

        allow 192.168.1.1/24;
        deny all;
    }
}

Answer 1

No, you cannot use limit_except at the server context level. It is only valid within a location context, per the ngx_http_core_module documentation:

Syntax: limit_except method ... { ... }

Default: —

Context: location

Approach #1 is the workaround/alternative for similar functionality, with the caveat that your example will give a HTTP status 405 response, instead of the 403 status that limit_except will respond with.