27

我有一个通过 HTTPS 与服务器上的 RESTful API 通信的移动设备。其中一项操作是数据同步，以将离线时所做的修改推送到服务器，并下拉服务器上并行进行的更新。

我遇到了一个边缘情况，即同步操作可能在现有客户端中静默失败。我已经升级了客户端上的“同步协议”以正确处理这种情况。理想情况下，我希望所有老客户在尝试同步时都会收到一条消息，告诉他们升级。

通信只是在我的服务器和我的移动客户端之间进行，所以我意识到我可以返回任意数量的 HTTP 代码并向客户端发出信号，以在未来显示一条消息，建议用户升级并立即停止同步过程。

是否会被视为对 HTTP 426 Upgrade Required 返回码的意图的混蛋，以使用它来表示这一点。我能找到的每一个参考资料（IETF RFC 2817，维基百科）都谈到使用它来向客户端发出信号以升级到 TLS。它是否意味着仅限于定义良好的/安全协议，如 SSL 和 TLS，或者它是 HTTP 层的通用升级标志，传统上仅用于 SSL 和 TLS？

如果它不适用于此用例，那么 HTTP 303 See Other 会被认为更合适，还是我缺少其他代码？

4

2 回答 2

15

引用我之前的一个答案：

HTTP 升级用于指示切换到不同版本的 HTTP 或其他协议的偏好或要求，如果可能的话：

The Upgrade general-header allows the client to specify what 
additional communication protocols it supports and would like to use 
if the server finds it appropriate to switch protocols. The server 
MUST use the Upgrade header field within a 101 (Switching Protocols) 
response to indicate which protocol(s) are being switched.

      Upgrade        = "Upgrade" ":" 1#product

  For example,

     Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

The Upgrade header field is intended to provide a simple mechanism 
for transition from HTTP/1.1 to some other, incompatible protocol.

根据IANA 注册，只有 3 次注册提及它（包括 HTTP 规范本身中的一次）。

另外两个用于：

（从那时起，IANA 注册簿就没有改变过。）

RFC 2817中定义的 426 响应代码显然与 RFC 2816 中定义的“HTTP 升级”意义上的升级有关。这是对当前使用层（即 HTTP 本身）的当前协议的更改。（甚至根本不是从升级http://到升级https://。）

在 HTTP 之上交换的消息（如果是协议的一部分）不属于此部分。就 HTTP 而言，它们只是超媒体实体。

如果您更改超媒体的含义，我认为 426 不适合。普通的 400 可能是更好的选择。请注意，带有错误状态代码（4xx、5xx）的响应不会阻止您在响应中关联实体：这是告诉客户端升级您的协议（在该级别）的消息应该位于的位置。

于 2013-07-26T10:49:22.747 回答
9

我同意布鲁诺的观点，即 426 不是最佳选择。400更好，但我认为403更好。

10.4.4 403 禁止

服务器理解请求，但拒绝执行。授权将无济于事，并且不应重复请求。如果请求方法不是 HEAD 并且服务器希望公开请求未完成的原因，它应该在实体中描述拒绝的原因。如果服务器不希望向客户端提供此信息，则可以使用状态代码 404（未找到）来代替。

Twitter API上有这方面的先例。

自 2014 年 2 月 26 日起，api.twitter.com 为所有非 SSL 传入流量返回 403 状态代码。您的客户端代码应该能够处理此错误。

于 2014-04-17T01:05:38.787 回答