一般web服务支持GET、HEAD和POST方法来检索静态和动态内容。
公开的web服务不应该支持其他HTTP(例如OPTIONS, TRACE)方法，因为它们增加了攻击面。
通常生产环境下应该禁用这些方法（如果您确实不需要该方法）
TRACE方法安全隐患:
开启TRACE方法可能导致Cross-Site Tracing（允许跨站点跟踪）攻击，该攻击可以捕获另一个应用程序用户的会话ID。
并且，该方法还可以用来尝试识别有关应用程序操作的环境的附加信息(例如，应用程序路径上是否存在缓存服务器)。
OPTIONS方法安全隐患:
开启OPTIONS方法并不会产生直接威胁，但攻击者可以从OPTIONS方法响应获取额外信息的来源，进而被攻击者利用已知漏洞。
HEAD方法安全隐患:
开启HEAD方法同样存在风险：尽管它并不被认为是危险的， 但它可以被用来通过模仿GET请求来攻击web应用程序。
其次，使用HEAD可以通过限制服务器发送的数据量来加快攻击进程。
如果授权机制基于GET和POST，那么HEAD方法可以允许绕过这些保护。
我认为，HEAD请求通常被代理或CDN用来有效地确定一个页面是否已经改变，而不需要下载整个页面(它对于检索写在响应头中的元信息很有用)。
更重要的是，如果禁用它，只会增加吞吐量成本。
如何通过
nginx拦截HTTP方法?
在配置拦截任何一种方法之前，需要了解401、403和405 HTTP这几个响应代码之间差异，建议使用405状态码：
- 1:
405 Method Not Allowe表示服务端不允许使用当前类型HTTP方法请求当前uri - 2:
401 Unauthorized表示当前用户未经认证授权，无权访问当前uri - 3:
403 Forbidden表示当前用户未通过鉴权，无权访问当前uri
在我看来，如果uri不能用给定的HTTP方法处理请求，它应该发送一个Allow头来列出允许的HTTP方法。 为此，您可以使用add_header添加响应信息。
推荐配置
server {
...
# If we are in server context, it’s good to use construction like this:
add_header Allow "GET, HEAD, POST" always;
if ($request_method !~ ^(GET|HEAD|POST)$) {
# You can also use 'add_header' inside 'if' context:
# add_header Allow "GET, HEAD, POST" always;
return 405;
}
...
}