假设我的服务器公开了一个基于http的api，它使用RFC 5789引入的PATCH方法。在企业防火墙、代理服务器、缓存、家长控制过滤器之类的客户端（浏览器或其他）之后，使用这种方法会遇到什么问题吗？如果是的话，这种可能性有多大？
考虑到PATCH不是最初http规范的一部分，而是稍后介绍的，我可以想象一些程序会因为“无效”方法而简单地拒绝此类请求。另一方面，我希望这样的软件能够简单地传递所有内容，并且最多对某些http方法应用一些限制，例如POST（例如不缓存其结果）。
请注意，我不询问服务器端或浏览器内的PATCH支持，而只询问客户端和服务器之间的组件，这些组件我既不知道也不控制。另外，对于api来说，PATCH本身是否是一个好主意的问题超出了这个问题的范围。
最佳答案
这个问题的答案是一个移动的目标。随着时间的推移，补丁程序变得越来越流行，网络中的系统可能支持，也可能不支持。
通常，只关心HTTP谓词的网络实体将是OSI Level 3（IP）和UP设备（防火墙、代理）。其中一些是“哑”的，因为他们不检查OSIlevel4（TCP）。另一些则是“聪明的”，可以执行协议级别的强制。例如，它们将阻止您打开端口80并发送stmp消息。
即使设备是“智能”的，它仍然可以配置为允许或不允许更不常见的http动词，如patch。因此，现在我们必须考虑到托管设备的组织的安全态势。星巴克（starbucks）和机场等开放wifi的地方可能会相当严苛，并会锁定安全。对一些公司来说也是如此，尤其是在处理敏感数据（财务、个人信息）时。
结果是，根据用户的人口统计，如果没有回退机制，修补程序可能会有问题。我认为以下领域的受限用户更有可能出现问题：敏感的公司环境、学校、军事组织。
关于http - 可以在代理等中安全地使用HTTP方法“PATCH”吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/30727345/