网站上多了一个 HTTP 方法：这类底层变化该关注什么

admin

简单说，多了一种查东西的方法

运维群里前天有人贴了张截图，抓包里请求行开头那几个字母他没见过，问是什么。那是一个刚写进标准的方法，公开的标准编号是 RFC 10008，名字叫 QUERY。它想解决一个老别扭：查询条件很长的时候，塞进地址里不合适，用 POST 又不太对劲。群里几个人也说不上来，最后还是翻了标准文档才确定。

现在常用的两个方法各有各的脾气。GET 把参数全放在地址里，地址长度有限，内容还会被完整记进日志和缓存，条件一多就撑不住。POST 带一个请求体，装得下，但它在语义上是要改点什么，很多缓存和网关看到 POST 就直接跳过处理。两边都差着一口气，所以才有这个新东西。

新方法的位置在两者之间：带请求体，把条件放进去，语义上只是查询，不期望改动数据。对写代码的人来说这是好事，接口能表达得更准。对运维和安全来说，多了一种方法，就是多了一份要照看的东西，凡是多出来的，都得先想清楚默认怎么处理。

麻烦都在不认识这三个字上

一个方法刚进标准，最先跟不上的不是开发，是中间那些设备。访问规则、防护设备、网关、缓存、日志解析，它们内部大多有一张允许的方法清单，新名字不在清单上，行为就不一样。平时看不出来，遇到新方法就露馅，而且它们不会主动告诉你。

有的直接拦掉，这算好的，至少失败了你知道原因。有的直接放过去，因为配置写的是「不在黑名单里就放行」，这类最需要留意。还有的会返回一个看不懂的错误，你在前端查半天，最后发现是中间那层不认识这个方法。这三类里，最该盯的就是中间那类。

麻烦的是这三类设备可能同时存在，而且日志里表现不一样。同一次请求，防护设备记的是被拦，网关记的是返回了错误，后端根本没收到。排这种问题特别费时间，因为每一层的说法都对，就是凑不到一起。所以排查的第一步，是先确认请求到底停在了哪一层。

该关注的那几样东西

第一样是访问规则。把自家在用的规则翻出来，看它是白名单放行还是黑名单拦截。白名单的思路更稳，只放行明确要用的方法，其他一律拒。黑名单的思路看着省事，但每来一个新东西，你都默认接受了它。这套规则翻一遍，花不了多少时间。

第二样是日志。日志字段里如果只记方法名，那没事；如果方法名是枚举类型的，遇到新值可能写成空、写成未知，甚至整条丢掉。这类丢日志的情况最烦，出事的时候你以为那段时间没请求，其实是被过滤掉了。看到方法字段偶尔空着，就值得多问一句。

第三样是那些只认 GET 和 POST 的老组件。有些自研的小工具、老插件、内部脚本，判断逻辑就是「不是 GET 就按 POST 处理」，或者「两种之外就报错」。平时看不出来，遇到不常见的方法就露馅了。清单里标出来，比临时救火强。老组件不一定会报错，它可能只是给了一个错的结果。

默认挡住比默认放行安全

这一条是整件事的落点。安全配置有个通用的思路：只允许明确需要的，其余全部拒绝。方法这一层也一样。自家网站实际用哪几种方法，多数情况下就那么两三种，把它们列出来放行，剩下的默认挡掉，规则短，维护也简单。列清楚之后，整份规则反而更容易看懂。

有人担心这样会误伤。确实会，但那是一次性的误伤，改一次规则就好了；而默认放行的代价是长期的、看不见的，你根本不知道有多少不认识的请求正在被处理。两种代价放在一起看，哪个划算很清楚。该拦的拦干净，比事后一遍遍解释划算得多。

落地的时候有两个动作：一是在防护设备和网关上都把方法清单显式写出来，别依赖默认；二是把不认识的方法的响应设成明确的拒绝，而不是让它走进后面的处理逻辑。这两步做完，你再去看日志，心里就有数了。以后有人问起，你也能说清为什么这么配。

抽一台机器自己看一眼

别急着全网改。先找一台自家的网站，或者在测试环境里建一个，看它对不常见方法的响应是什么。是干脆拒绝，还是转给了后端，还是返回一个含糊的错误。这一步不复杂，看一眼就知道现在是什么状况。看之前先想清楚，你期望它返回什么。

顺便看看中间那几层的说法是不是一致。防护设备怎么记的、网关怎么记的、后端有没有收到，三边对一遍。对不上的地方，就是将来排查时要吃亏的地方，现在补上说明和规则，比出事时临时猜要省事得多。别等真出事那天，才发现三边的说法对不上。

给个实在的做法：这周把自家网站的访问规则翻出来，看看它是白名单还是黑名单，把不认识的方法默认拒绝这条补上，再把日志里方法字段的类型确认一遍。这两件事做完，比升级任何设备都管用。这件事不花预算，只花一点耐心，做完就能一直用。