我有一个移动设备通过HTTPS与我服务器上的RESTful API进行通信。其中一项操作是数据同步,用于将脱机时所做的修改推送到服务器,并下拉服务器上并行进行的更新。
我遇到了一个边缘情况,即同步操作可能会在现有客户端中静默失败。我已经升级了客户端上的“同步协议”以正确处理条件。理想情况下,我希望让所有旧客户端在尝试同步时告知他们升级时收到消息。
通信就在我的服务器和我的移动客户端之间,所以我意识到我可以返回任意数量的HTTP代码并通知客户端将来显示一条消息,建议用户升级并立即停止同步过程。 / p>
它是否会被视为对HTTP 426升级所需返回代码的意图的混淆,以使用它来发出信号。我可以找到的每个引用(IETF RFC 2817,Wikipedia)都说使用它来通知客户端升级到TLS。它是否仅限于SSL和TLS等定义明确的安全协议,还是HTTP层的通用升级标志,传统上只用于SSL和TLS?
如果不是针对此用例,那么HTTP 303 See Other会被认为是更合适还是还有其他代码我不知道?
答案 0 :(得分:12)
引用我的previous answers之一:
HTTP Upgrade用于表示偏好或要求 切换到不同版本的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 register,只有3个注册 提及它(包括HTTP规范本身中的一个)。
另外两个是:
Upgrading to TLS Within HTTP/1.1(几乎从不使用,不是 与HTTP over TLS混淆,后者将HTTPS定义为广泛的 用过的)。此升级允许for a similar mechanism to STARTTLS in other protocols(例如LDAP,SMTP,...)以便能够切换 交换一些后,在与普通连接相同的端口上进行TLS 应用程序协议消息,而不是整个 在SSL / TLS之上进行HTTP交换而不需要知道它在顶部 TLS(HTTPS的工作方式)。
Upgrading to WebSockets(仍然是草案)。
(自那时以来,IANA注册没有变更。)
RFC 2817中定义的426响应代码显然与RFC 2816中定义的“HTTP升级”意义上的升级有关。这是当前协议的更改当前使用的层(即HTTP本身)。 (甚至根本不是从http://
升级到https://
。)
在HTTP之上交换的消息(如果是协议的一部分)不属于此类。就HTTP而言,它们只是超媒体实体。
如果你改变超媒体的含义,我认为426不合适。平原400可能是更好的选择。请注意,具有错误状态代码(4xx,5xx)的响应不会阻止您在响应中关联实体:这是告知客户端升级协议(在该级别)的消息应该是。
答案 1 :(得分:8)
我同意布鲁诺的观点,认为426不是最好的选择。 400更好,但我认为403更好。
10.4.4 403禁止
服务器理解请求,但拒绝履行请求。授权无效,请求不应重复。如果请求方法不是HEAD并且服务器希望公开为什么请求没有得到满足,那么它应该描述实体中拒绝的原因。如果服务器不希望将此信息提供给客户端,则可以使用状态代码404(未找到)。
Twitter API上有先例。
自2014年2月26日起,api.twitter.com将返回所有非SSL传入流量的403状态代码。您的客户端代码应该能够处理此错误。