2013-07-26 56 views
17

我有一個移動設備通過HTTPS與我的服務器上的RESTful API進行通信。其中一項操作是數據同步,用於將在離線狀態下進行的修改推送到服務器,並在服務器上並行執行更新。HTTP狀態碼是否需要升級僅需要升級到安全通道的信號?

我遇到了一個邊緣情況,那個同步操作可能會在現有客戶端中靜默失敗。我已升級客戶端上的「同步協議」以正確處理條件。理想情況下,我想讓所有較舊的客戶端在嘗試同步時收到一條消息,告訴他們升級。

通信只是在我的服務器和我的移動客戶端之間,所以我意識到我可以返回任意數量的HTTP代碼,並通知客戶端將來會顯示一條消息,建議用戶升級並立即停止同步過程。

它會被視爲HTTP 426 Upgrade Required返回碼的意圖的混蛋,用它來表示這一點。每個參考(IETF RFC 2817,Wikipedia)我可以找到說話使用它來發信號通知客戶端升級到TLS。是否僅限於定義良好的/安全協議(如SSL和TLS),還是僅在傳統上僅用於SSL和TLS的HTTP層的通用升級標誌?

如果不是爲了這個用例,HTTP 303 See Other會被認爲更合適還是有另一個我錯過的代碼?

+0

[RFC 2616](http://tools.ietf.org/html/rfc2616#section-14.42)說你必須告訴客戶端「升級」到什麼地方。如果你能適合你的用例,那可能不是混蛋。 ;) – Sven

回答

11

引用我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規範本身中的一個)。

另外兩個是:

(IANA的寄存器從那時起沒有改變。)

RFC 2817限定的426響應代碼顯然有與RFC定義中的「HTTP升級」感升級到做這是在當前使用的層(即,HTTP本身)處改變當前協議。(甚至根本沒有從http://https://的升級。)

在HTTP之上交換的消息(如果是協議的一部分)不是這個的一部分。就HTTP而言,它們只是超媒體實體。

如果您改變超媒體的含義,我認爲426並不適合。平原400可能是更好的選擇。請注意,帶有錯誤狀態代碼(4xx,5xx)的響應不會阻止您在響應中關聯實體:這是一條告訴客戶端升級您的協議(在該級別)的消息的位置。

4

我同意布魯諾說426不是最好的選擇。 400更好,但我認爲403還是更好。

10.4.4 403禁止

服務器理解了請求,但拒絕執行。授權不起作用,請求不應重複。如果請求方法不是HEAD並且服務器希望公開爲什麼請求沒有被滿足,那麼它應該描述在實體中拒絕的原因。如果服務器不希望將該信息提供給客戶端,則可以使用狀態碼404(未找到)代替。

Twitter API上有這個先例。

自2014年2月26日起,api.twitter.com將爲所有非SSL傳入流量返回403狀態碼。你的客戶端代碼應該能夠處理這個錯誤。