Ist der HTTP-Statuscode 426 Upgrade erforderlich, bedeutet dies nur, dass ein Upgrade auf einen sicheren Kanal erforderlich ist?

Question

Ich habe ein mobiles Gerät, das über HTTPS mit einer RESTful-API auf meinen Servern kommuniziert. Eine der Operationen ist eine Datensynchronisierung, um Änderungen, die offline an den Server vorgenommen wurden, zu übertragen und Aktualisierungen auf dem Server parallel durchzuführen.

Ich habe einen Edge-Fall festgestellt, bei dem der Synchronisierungsvorgang im vorhandenen Client unbemerkt fehlschlagen kann. Ich habe das "Sync-Protokoll" auf dem Client aktualisiert, um den Zustand richtig zu behandeln. Idealerweise möchte ich, dass alle älteren Clients eine Nachricht erhalten, wenn sie versuchen, sie zu synchronisieren, damit sie sie aktualisieren können.

Die Kommunikation besteht nur zwischen meinem Server und meinem mobilen Client. Daher stelle ich fest, dass ich eine beliebige Anzahl von HTTP-Codes zurückgeben kann und dem Client eine Nachricht in der Zukunft anzeigen kann, die den Benutzer auffordert, den Synchronisierungsprozess sofort zu beenden.

Wäre es als eine Bastardisierung der Absicht des HTTP 426 Upgrade Required Return-Code zu sehen, um es zu signalisieren. Jede Referenz (IETF RFC 2817, Wikipedia) kann ich finden, um es zu verwenden, um einem Client zu signalisieren, auf TLS zu aktualisieren. Soll es auf genau definierte Sicherheitsprotokolle wie SSL und TLS beschränkt sein oder handelt es sich um ein generisches Upgrade-Flag auf der HTTP-Ebene, das bisher nur für SSL und TLS verwendet wurde?

Wenn es nicht für diesen Anwendungsfall gedacht ist würde ein HTTP 303 Siehe Andere geeigneter sein oder gibt es einen anderen Code, den ich vermisse?

Answer 1

Zitiert einer meiner previous answers:

HTTP Upgrade wird verwendet, um eine Präferenz oder Anforderung Umstellung auf eine andere Version von HTTP oder auf ein anderes Protokoll, um anzuzeigen, wenn möglich:

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. 

Laut der IANA register gibt es nur 3 registrierte Erwähnungen davon (einschließlich einer in der HTTP-Spezifikation selbst).

Die anderen beiden sind für:

• Upgrading to TLS Within HTTP/1.1 (fast nie verwendet, nicht zu mit HTTP over TLS verwechselt werden, die HTTPS definiert als weit verwendet). Dieses Upgrade ermöglicht for a similar mechanism to STARTTLS in other protocols (z. B. LDAP, SMTP, ...), um zu TLS auf dem gleichen Port wie die einfache Verbindung zu wechseln, nach dem Austausch einiger der der Anwendungsprotokollmeldungen, im Gegensatz zu den gesamten HTTP-Austausch über SSL/TLS ohne es zu wissen, ist es oben von TLS (die Art, wie HTTPS funktioniert).

• Upgrading to WebSockets (noch ein Entwurf).

(Die IANA-Register seitdem nicht geändert haben.)

Der 426-Antwortcode wie in RFC 2817 eindeutig im definiert in RFC mit einem Upgrade zu tun hat, definiert "HTTP Upgrade" Sinn 2816. Dies ist eine Änderung des aktuellen Protokolls auf der aktuell verwendeten Schicht (dh HTTP selbst).(Es geht überhaupt nicht um ein Upgrade von http:// auf https://.)

Die Nachrichten, die über HTTP ausgetauscht werden (wenn überhaupt ein Teil eines Protokolls), sind nicht Teil davon. Sie sind nur Hypermedia-Entitäten, was HTTP betrifft.

Ich glaube nicht 426 wäre geeignet, wenn Sie die Bedeutung Ihrer Hypermedia ändern. Eine einfache 400 wäre wahrscheinlich eine bessere Wahl. Beachten Sie, dass Antworten mit Fehlerstatuscodes (4xx, 5xx) Sie nicht daran hindern, eine Entität in der Antwort zuzuordnen: Hier sollte eine Nachricht sein, die dem Client mitteilt, Ihr Protokoll (auf dieser Ebene) zu aktualisieren.

Answer 2

Ich stimme mit Bruno überein, dass 426 nicht die beste Wahl ist. 400 ist besser, aber ich denke, 403 ist noch besser.

10.4.4 403

Verbotene

Der Server versteht die Anfrage, aber weigert sich, sie zu erfüllen. Die Autorisierung wird nicht helfen und die Anfrage sollte nicht wiederholt werden. Wenn die Anfrage-Methode nicht HEAD war und der Server öffentlich machen wollte, warum die Anfrage nicht erfüllt wurde, SOLLTE der Grund für die Ablehnung in der Entität beschrieben werden. Wenn der Server diese Informationen dem Client nicht zur Verfügung stellen möchte, kann stattdessen der Statuscode 404 (Not Found) verwendet werden.

Es gibt Präzedenzfälle dafür auf der Twitter API.

Seit dem 26. Februar 2014 gibt api.twitter.com den 403-Statuscode für den gesamten eingehenden Datenverkehr ohne SSL zurück. Ihr Client-Code sollte in der Lage sein, diesen Fehler zu behandeln.