假设我的服务器公开了一个使用RFC 5789PATCH引入的方法的基于 HTTP 的 API 。公司防火墙、代理、缓存、家长控制过滤器等后面的客户端（浏览器或其他）是否有可能在使用此方法时遇到任何问题？如果是这样，这种可能性有多大？
鉴于这PATCH不是原始 HTTP 规范的一部分，而是稍后介绍的，我可以想象某些程序会因为“无效”方法而简单地拒绝此类请求。另一方面，我希望这样的软件可以简单地通过所有东西，并且最多对某些 HTTP 方法应用一些限制，例如POST（例如不缓存其结果）。
请注意，我不询问PATCH服务器端或浏览器内的支持，而只是询问我既不知道也不控制的客户端和服务器之间的组件。此外，PATCH对于 API 本身是否是一个好主意的问题超出了这个问题的范围。
这个问题的答案是一个移动的目标。随着时间的推移和 PATCH 变得越来越流行，网络中的系统可能支持也可能不支持它。
通常，只有关心 HTTP 动词的网络实体才会是OSI 级别3 (IP) 和更高级别的设备（防火墙、代理）。其中一些是“愚蠢的”，因为它们不检查 OSI 级别 4 (TCP)。其他人是“聪明的”，可以进行协议级别的强制执行。例如，它们会阻止您打开端口 80 并发送 STMP 消息。
即使设备是“智能”的，它仍然可以配置为允许或不允许更多不常见的 HTTP 动词，如 PATCH。因此，现在我们必须考虑托管设备的组织的安全状况。像星巴克和机场这样开放 wifi 的地方可能会非常严苛，并且会封锁安全。一些公司也是如此，尤其是在他们处理敏感数据（财务、个人信息）时。
结果是，根据您的用户的人口统计，如果您没有回退机制，PATCH 可能会出现问题。我认为以下领域的受限用户更有可能遇到问题：敏感的公司环境、学校、军事组织。