有没有人遇到PATCH方法超过XHR（AJAX请求）被防火墙阻止的情况？
基本上我们遇到一个客户抱怨他无法更新应用内容的情况。我们在它工作的世界的任何地方检查过它（我们通过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，客户是Schools =＆gt;他们不一定可能在他们的网络堆栈上拥有最新技术。也可以预设保姆软件。
在同一问题上交叉引用Reddit讨论：https://www.reddit.com/r/rest/comments/5gkvba/patch_blocked_by_firewall/
答案 0 :(得分：4)
仍然不太清楚为什么会这样，但我很确定，因为PATCH方法比防火墙设置更年轻。
基本上正确的解决方法是用POST取代PATCH，因为两者都是非幂等的。
HTTP标准最佳实践告诉您不应该用PUT替换它，尽管一些Web框架（如Ruby on Rails）使它变得太简单了。问题是由于中间设备重复PUT因为它是幂等的，你最终可能会遇到其他问题。
我在文章http://www.eq8.eu/blogs/37-post-create-and-put-updatepost
中总结了整个故事