10

我正在研究 RESTfully 版本控制 API 的各种方法，其中有三个主要的竞争者。我相信我几乎已经决定使用X-API-Version. 撇开争论不谈，反对使用该标头和自定义标头的论据之一是您无法控制标头何时由代理服务器操作。我很好奇有哪些现实世界的例子，什么时候发生在整个互联网上，或者什么时候可能在内部网或服务器集群上使用，或者它可能发生在任何其他情况下。

4

2 回答 2

17

Web内容转换代理指南 1.0几乎是理解和预测符合标准的代理服务器行为的权威指南。就您的问题而言，文档的请求的代理转发部分可能特别有用。

每个代理软件包及其各自的配置都会有所不同，但 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] 要求的修改之外，代理不应修改除User-Agent、Accept、Accept-Charset、Accept-Encoding和Accept-Language标头字段以外的标头字段的值，并且不得删除标头字段（请参阅 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 标头字段

无论是否存在 no-transform 指令：

  • 代理应将请求发起者的 IP 地址添加到 X-Forwarded-For HTTP 标头字段中逗号分隔列表的末尾；

  • 代理必须（根据 RFC 2616）包括一个通过 HTTP 头字段（请参阅 4.1.6.1 通过头字段的代理处理）。

还有很多关于响应标头更改以及能够检测到这些更改的信息。

至于 Web 服务 REST API 版本控制，API 版本控制的最佳实践中有一个非常清晰和有用的 SO 线程？这应该提供大量有用的见解。

我希望所有这些都会有所帮助。小心。

于 2014-01-20T05:46:43.740 回答
4

这本身不是一个答案，而是对现实世界场景的提及。

我当前的环境使用混合的 CAS/AD 解决方案，以允许跨多个不同平台（经典 ASP、ASP.NET、J2EE 等）的 SSO。

最近我们发现了一些问题——解决方案的一部分涉及在传播凭证时将 Auth 令牌聚合到 HTTP 标头。一个特定的解决方案，大量使用 cookie，与 nginx 实现链接，其 HTTP 标头限制设置为 4KiB。如果 cookie 有效负载超过 2KiB，它将开始泄漏标头。

因此，通过 HTTP 标头（包括会话 cookie）进行某种状态/范围控制的应用程序突然开始出现异常行为。

在一个有趣的相关说明中，使用 URL 版本控制（http://server/api/vX.X/resource例如）的 REST 服务不受影响。

于 2014-01-14T17:00:13.540 回答