我正在研究RESTs版本化API的各种方法，并且有三个主要的竞争者。我相信我已经决定使用X-API-Version。抛开这个争论，反对使用该标头和一般自定义标头的一个论点是，您无法控制何时由代理服务器操纵标头。我很好奇这个实际的例子，当它发生在互联网上，或者它可能在内部网或服务器集群上使用时，或者它可能在任何其他情况下发生时。
答案 0 :(得分：15)
Guidelines for Web Content Transformation Proxies 1.0几乎是理解和预测符合标准的代理服务器行为的权威指南。就您的问题而言，文档的Proxy Forwarding of Request部分可能特别有用。
每个代理软件包及其各自的配置会有所不同，但HTTP代理通常应遵循W3C指南。以下是一些亮点。
4.1代理转发：
除了在HEAD和GET代理之间进行转换之外，不得改变请求方法。
如果请求包含Cache-Control：no-transform指令，则除了遵守[RFC 2616 HTTP]部分第14.9.5节和第13.5.2节中定义的透明HTTP行为之外，代理不得更改请求。添加标题字段，如下面4.1.6附加HTTP标头字段中所述。
4.1.3处理非Web浏览器的请求者
在更改HTTP请求和响应的各个方面之前，代理需要考虑到HTTP被用作“传统浏览”以外的许多应用程序的传输机制这一事实。越来越多的基于浏览器的应用程序涉及使用XMLHttpRequest进行数据交换（参见4.2.8转换代理决策），这种交换的更改可能会导致误操作。
4.1.5更改HTTP标头字段值
除了[RFC 2616 HTTP]代理所需的修改之外，不修改用户代理以外的标题字段的值，接受， Accept-Charset ，接受编码，接受语言标题字段，不得删除标题字段（参见4.1.5.5原始标题字段）。
除了遵守透明的HTTP操作之外，代理不应修改任何请求头字段，除非满足以下条件之一：
由于服务器响应该请求是“不可接受的”（见4.2.4服务器拒绝HTTP请求），将禁止用户访问内容;
用户已明确要求重组桌面体验（参见4.1.5.3用户选择重组体验）;
请求是一系列请求的一部分，包括同一网站上包含的资源或链接资源（参见4.1.5.4请求顺序）。
以下各节详细介绍了这些情况。
注意：
需要强调的是，在存在Cache-Control：no-transform时，不得更改请求，如请求中的4.1.2 no-transform指令所述。
请求中引用的URI不参与确定是否更改HTTP请求标头字段值。特别是4.2.8转换代理决策中提到的模式并不重要。
4.1.6其他HTTP标头字段
无论是否存在无变换指令：
代理应将请求的发起者的IP地址添加到X-Forwarded-For HTTP头字段中逗号分隔列表的末尾;
代理必须（根据RFC 2616）包含Via HTTP头字段（参见4.1.6.1 Via Header字段的代理处理）。
还有很多关于响应头的更改以及能够检测到这些更改的信息。
对于Web服务REST API版本控制，Best practices for API versioning?上有一个非常清晰且有用的SO线程，应该提供大量有用的洞察力。
我希望所有这一切都有帮助。小心。
答案 1 :(得分：1)
这本身不是答案，而是提及现实世界的情景。
我当前的环境使用混合的CAS / AD解决方案，以允许SSO跨越多个不同的平台（经典ASP，ASP.NET，J2EE，您可以命名）。
最近我们发现了一些问题 - 解决方案的一部分涉及在必要时将Auth令牌聚合到HTTP头以传播凭据。一个特定的解决方案，大量使用cookie，与nginx实现链接，其HTTP标头限制设置为4KiB。如果cookie有效载荷超过2KiB，它将开始泄漏标题。
因此，通过HTTP标头（包括会话cookie）协调某种状态/范围控制的应用程序突然开始表现不正常。
在一个有趣的相关说明中，使用URL版本控制（例如http://server/api/vX.X/resource）的REST服务不受影响。