防火墙阻止了PATCH方法吗？

Question

大家有没有遇到过通过 XHR（AJAX 请求）发送的 PATCH 方法被防火墙拦截的情况？

基本上，我们遇到了这样一种情况：客户抱怨他无法在我们的应用程序中更新内容。我们在全球各地检查了这个问题（我们通过 VPN 连接了几个地方），都没有发现问题。

然后他们为我们提供了一个远程桌面（最新的 Windows，最新的 chrome），所以我们在他们的网络环境下尝试了一下，结果发现他们说得对。通过 AJAX 调用的所有 PATCH 方法都会出现 405 错误，但是所有的 PUT POST DELETE GET 方法都可以正常使用。我们试图在应用程序和 Nginx 日志中跟踪这些 PATCH 请求，但似乎它们从未到达我们的服务器。因此，结论是他们的防火墙永远不会让请求离开他们的建筑物。

译文:

| Laptop PATCH  ->  Clients Firewal   ->   Load Balancer   ->  Nginx proxy  -> Rails app (200 response) |

这个防火墙案例：

| Laptop PATCH ->  Clients Firewal  (405 response)   |

由于时间不够，我们只将部分有问题的端点从PATCH更改为PUT，一切正常！

我唯一的解释是因为PATCH属于另一个（后引入的）RFC，他们的防火墙可能非常旧，并且无法将PATCH注册为有效的方法。他们的系统管理员不知道为什么会出现这种情况。但是一个线索是该应用程序是EdTech，客户是学校，因此他们不一定具备最新的网络技术堆栈。还可能预设了保姆软件。

交叉参考Reddit上同样问题的讨论：https://www.reddit.com/r/rest/comments/5gkvba/patch_blocked_by_firewall/

- equivalent8

---

你能更具体地说明防火墙的名称和版本吗？ - kometen

很抱歉，我不能这样做。我们从客户那里收到的支持和信息知识在某种程度上几乎是“我们不知道”。我们唯一能做的就是尝试从远程桌面进行调用。不幸的是，我不再拥有标题信息，但我记得的一件事是，在发生405错误时，头部有“Squid”头。那么Squid是否缓存了PATCH呢？（因为PATCH是可缓存的） - equivalent8

好的，听起来他们尽力帮忙了。我对Squid不是很了解，但它确实表明设置非常老旧。 - kometen

在过去，我们只需切换到https。大多数防火墙都不会干扰https流量。 - 9Rune5

这个问题发生在 HTTPS 下，不幸的是整个应用都在 HTTPS 下，但是这是个好主意。 - equivalent8

Answer 1

我还不太清楚为什么会发生这种情况，但我相信这可能是由于PATCH方法比防火墙设置更新导致的。

基本上正确的解决方法是将PATCH替换为POST，因为两者都是非幂等的。

HTTP标准最佳实践告诉我们不应该将其替换为PUT，尽管一些Web框架（如Ruby on Rails）使它变得非常容易。问题在于，由于PUT是幂等的，中间设备会重复传输，从而导致其他问题。

我在文章http://www.eq8.eu/blogs/37-post-create-and-put-updatepost中总结了整个故事。

- equivalent8