我正在研究RESTfully版本控制API的各种方法，有三个主要的竞争者。我相信我几乎已经决定使用X-API-Version了。抛开这场争论不谈，反对使用该标头以及通常的自定义标头的论点之一是，您无法控制代理服务器何时操作标头。我很好奇现实世界中有什么这样的例子，当它在互联网上发生时，或者当它可能在内联网或服务器集群上使用时，或者它可能在任何其他情况下发生时。
Web内容转换代理1.0指南几乎是理解和预测符合标准的代理服务器行为的权威指南。就您的问题而言，文档中的代理转发请求部分可能特别有用。
每个代理软件包及其各自的配置都会有所不同，但HTTP代理通常应遵循W3C准则。以下是一些亮点。
4.1代理转发请求:
除了在HEAD和GET代理之间转换之外，其他代理不得更改请求方法。
如果请求包含Cache-Control:no-transform指令，则代理不得更改请求，除非遵守[RFC2616HTTP]第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]所需的修改之外，代理应该不修改用户代理、接受和接收字符集之外的头字段的值，和接受语言标题字段，且不得删除标题字段(请参见4.1.5.5原始标题字段)。
除了遵守透明HTTP操作外，代理不应修改任何请求标头字段，除非以下情况之一适用：
-
由于服务器响应请求"不可接受"，用户将被禁止访问内容(见4.2.4服务器拒绝HTTP请求)；
-
用户已明确要求重组桌面体验(见4.1.5.3重组体验的用户选择)；
-
请求是一系列请求的一部分，这些请求包括同一网站上包含的资源或链接的资源(见4.1.5.4请求序列)。
以下各节详细介绍了这些情况。
注意：
需要强调的是，在存在缓存控制的情况下，不得更改请求：请求中的4.1.2无转换指令中所述的无转换。
请求中引用的URI在决定是否更改HTTP请求头字段值方面没有任何作用。特别是4.2.8中提到的转换代理决策中的模式并不重要。
4.1.6其他HTTP头字段
无论是否存在无转换指令：
-
代理应将请求发起方的IP地址添加到X-Forwarded-ForHTTP标头字段中逗号分隔列表的末尾；
-
代理必须(根据RFC 2616)包括Via HTTP报头字段(参见4.1.6.1 Via报头字段的代理处理)。
还有很多关于响应标头的更改以及能够检测到这些更改的信息。
关于web服务REST API版本控制，API版本控制的最佳实践中有一个非常清晰和有用的SO线程？这应该会提供大量有益的见解。
我希望所有这些都能有所帮助。小心。
这本身并不是一个答案，而是对现实世界场景的提及。
我当前的环境使用混合的CAS/AD解决方案，以便允许跨多个不同平台(经典的ASP、ASP.NET、J2EE，您可以命名)执行SSO。
最近，我们发现了一些问题——解决方案的一部分涉及在必要时将Auth令牌聚合到HTTP标头中以传播凭据。一个特定的解决方案是大量使用cookie，它与nginx实现链接在一起，nginx的HTTP头限制设置为4KiB。如果cookie有效负载超过2KiB，它就会开始泄漏标头。
因此，通过HTTP头(包括会话cookie)协调某种状态/范围控制的应用程序突然开始出现不稳定的行为。
有趣的是，使用URL版本控制(例如http://server/api/vX.X/resource)的REST服务没有受到影响。