http - HTTP 方法 "PATCH"可以跨代理等安全使用吗？

Question

假设我的服务器公开了一个基于 HTTP 的 API，该 API 使用由 RFC 5789 引入的 PATCH 方法.公司防火墙、代理、缓存、家长控制过滤器等后面的客户端(浏览器或其他)是否有可能在使用此方法时遇到任何问题？如果是这样，这种可能性有多大？

鉴于 PATCH 不是原始 HTTP 规范的一部分，而是后来引入的，我可以想象某些程序会因为“无效”方法而简单地拒绝此类请求。另一方面，我希望这样的软件只是简单地传递所有内容，最多对某些 HTTP 方法(例如 POST)施加一些限制(例如不缓存其结果)。

请注意，我不询问服务器端或浏览器内的PATCH 支持，而只询问我既不知道也不控制的客户端和服务器之间的组件。此外，PATCH 本身对于 API 是否是一个好主意的问题超出了这个问题的范围。

Answer 1

这个问题的答案是一个移动的目标。随着时间的推移，PATCH 变得越来越流行或越来越不流行，网络中的系统可能支持也可能不支持它。

通常只有关心 HTTP 动词的网络实体才会是 OSI Level 3 (IP) 及以上设备(防火墙、代理)。其中一些是“愚蠢的”，因为它们不检查 OSI 级别 4 (TCP)。其他人则“聪明”，可以执行协议(protocol)级别的执行。例如，它们会阻止您打开端口 80 并发送 STMP 消息。

即使设备是“智能”的，它仍然可以配置为允许或不允许更多不常见的 HTTP 动词，如 PATCH。所以现在我们必须考虑托管设备的组织的安全状况。像星巴克和机场这样有开放式 wifi 的地方可能会非常严厉并且会锁定安全性。一些公司也是如此，尤其是当他们处理敏感数据(财务、个人信息)时。

结果是，根据用户的人口统计，如果您没有回退机制，PATCH 可能会出现问题。我认为以下领域中的受限用户更有可能遇到问题:敏感的企业环境、学校、军事组织。