引起这个问题的情况很明确，并不抽象。但我知道适用于它的变通方法，因此我省略了细节，以便获得回答这个问题的通用管道。
问题描述:假设你有一个locationNGINX块，你想在这个块中以不同的方式响应，这取决于请求的HTTP方法。但是NGINX不支持像location /:POST {...}这样的语法，需要一些更复杂的方法。
我试图找到这个问题的答案，我所有的发现可以分为以下几组:
组1:if ($request_method ...)insidelocation
但它是邪恶的。
对于我来说，如果不将指令从外部"common"复制到if子句中，纯粹的if方式是行不通的。空间。此外，所有复制的指令都不会被NGINX的开发人员批准。
只有return和rewrite被批准在if内，但这是不够的。
第二组:limit_except
如果你想限制某个位置的某些方法，这种方法是适用的。但是它不允许对同一位置的每个HTTP方法组区分行为。
组3:让map一切
许多if病例可以用一个/两个/…正确的map块。$request_method也可以被映射，但如果它是不够的或漂亮的只是map几次呢?例如，如何使用一个HTTP方法来proxy_pass请求，并对具有相同位置和另一个HTTP方法而没有if的请求执行try_files?(不是我的情况，只是if中不允许的两个不兼容指令的例子)。如何避免一次调节需要10+map。
组4:代理不同upstream块
这个方法很复杂，看起来有点小题大做。此外，如果您需要的不仅仅是代理(对于端点选择map就足够了)，您必须创建一个新的虚拟主机。而且实现的各个部分相距很远。
当我在写这个问题的时候，我想到了错误页面和命名位置的想法。然而，提出这个问题是为了收集更多的解决方案和意见，帮助别人。
自己的想法1:错误页面和命名位置
return允许返回错误代码而不显式重定向。但是通过提供非标准的错误代码，可以定义自己的错误处理程序来扩展功能。
有时我发现这个技术可以解决"重复的location指令"。问题(指令被放置在错误处理程序中，并且除了位置的不同指令之外，位置还返回处理程序的错误代码)。
使用例子:
map $request_method $handler_code {
GET 598;
POST 599;
default 405; # Method Not Allowed
}
server {
...
error_page 598 = @get_handler;
location @get_handler {
# only GET routine
}
error_page 599 = @post_handler;
location @post_handler {
# only POST routine
}
location / {
... # Common routine
return $handler_code;
...
}
...
}