Protocol upgrade mechanism

Traduzione in corso.

Il protocollo HTTP/1.1  fornisce uno speciale meccanismo che può essere utilizzato per aggiornare a una connessione già stabilita da un protocollo diverso, utilizzando il campo d'intestazione(Header) Upgrade ..

Questo meccanismo è opzionale; non può essere utilizzato per insistere su una modifica del protocollo. Le implementazioni possono scegliere di non sfruttare un aggiornamento anche se supportano il nuovo protocollo e, in pratica, questo meccanismo viene utilizzato principalmente per avviare una connessione WebSocket.

Notare anche che HTTP / 2 non consente esplicitamente l'uso di questo meccanismo; è specifico per HTTP / 1.1.

Aggiornamento delle connessioni HTTP/1.1

Il campo d'intestazione(Header) Upgrade viene utilizzato dai client per invitare il server a passare a uno dei protocolli elencati, in ordine decrescente.

Poiché Upgrade è un'intestazione(Header) hop-by-hop, deve essere elencata anche nel campo d'intestazione(Header) Connection . Ciò significa che una richiesta che include Upgrade sarebbe simile a:

GET /index.html HTTP/1.1
Host: www.example.com
Connection: upgrade

Potrebbero essere necessarie altre intestazioni(Header) a seconda del protocollo richiesto; for example, ad esempio, gli aggiornamenti di WebSocket consentono intestazioni (headers) aggiuntive per configurare i dettagli sulla connessione WebSocket e per offrire un certo grado di sicurezza nell'apertura della connessione. Vedi Upgrading to a WebSocket connection per maggiori dettagli.

Se il server decide di aggiornare la connessione, restituisce lo stato di risposta 101 Switching Protocols con un'intestazione d'aggiornamento (Upgrade header) che specifica il protocollo/i a cui passare. Se non aggiorna o non può farlo ignora l'Upgrade header e rimanda regolarmente una risposta (ad esempio, un 200 OK).

Subito dopo aver inviato lo status code 101, il server può iniziare ad utilizzare il nuovo protocollo, eseguendo ogni eventuale protocol-specific handshakes se necessario. In effetti, la connessione diventa una two-way pipe non appena la risposta aggiornata è completa, e le richieste che ha dato inizio all'aggiornamento può essere completata tramite il nuovo protocollo.

Usi comuni per questo meccanismo

Qui esaminiamo i casi d'uso più comuni per l' Upgrade del header.

Aggiornamento a una connessione WebSocket

Di gran lunga, il caso d'uso più comune per l'aggiornamento di una connessione HTTP è l'utilizzo di WebSocket, che vengono sempre implementati aggiornando una connessione HTTP o HTTPS. Tieni presente che se stai aprendo una nuova connessione utilizzando il WebSocket API, o qualsiasi libreria che esegue il WebSocket, la maggior parte se non tutto questo viene fatto per te. Ad esempio, l'apertura di una connessione WebSocket è semplice come:

webSocket = new WebSocket("ws://destination.server.ext", "optionalProtocol");

Il costruttore WebSocket() fa tutto il lavoro di creazione di una connessione iniziale HTTP / 1.1 e dopo gestisce l'handshaking e il processo di aggiornamento per te.

Puoi anche utilizzare lo schema URL "wss://" per aprire una connessione sicura WebSocket.

Se devi creare una connessione WebSocket da zero, dovrai gestire tu il processo di handshaking. Dopo aver creato la sessione iniziale HTTP / 1.1, è necessario richiedere l'aggiornamento aggiungendo a una richiesta standard gli Upgrade e Connection headers, come segue:

Connection: Upgrade
Upgrade: websocket

Specifiche di WebSocket headers

Le seguenti intestazioni sono coinvolte nel processo di aggiornamento del WebSocket. Oltre al Upgrade e Connection headers, the rest are generally optional or handled for you by the browser and server when they're talking to each other.

Sec-WebSocket-Extensions

Specifies one or more protocol-level WebSocket extensions to ask the server to use. Using more than one Sec-WebSocket-Extension header in a request is permitted; the result is the same as if you included all of the listed extensions in one such header.

Sec-WebSocket-Extensions: extensions
extensions
A comma-separated list of extensions to request (or agree to support). These should be selected from the IANA WebSocket Extension Name Registry. Extensions which take parameters do so by using semicolon delineation.

For example:

Sec-WebSocket-Extensions: superspeed, colormode; depth=16

Sec-WebSocket-Key

Fornisce al server le informazioni necessarie per confermare che il cliente ha il diritto di richiedere un aggiornamento a WebSocket. Questa intestazione (header) può essere utilizzata quando i clienti meno sicuri (HTTP) desiderano effettuare l'upgrade, al fine di offrire un certo grado di protezione contro gli attacchi. Il valore della chiave è calcolato utilizzando un algoritmo definito nelle specifiche del WebSocket, di conseguenza ciò non garantisce sicurezza. Invece, aiuta a prevenire che i client non WebSocket non richiedano inavvertitamente, o attraverso un uso improprio, una connessione WebSocket. In sostanza, quindi, questa chiave conferma semplicemente che "Sì, intendo davvero aprire una connessione WebSocket".

Questa intestazione(header) viene aggiunta automaticamente dai client che scelgono di usarla; non può essere aggiunta usando il metodo XMLHttpRequest.setRequestHeader().

Sec-WebSocket-Key: key
key
The key for this request to upgrade. The client adds this if it wishes to do so, and the server will include in the response a key of its own, which the client will validate before delivering the upgrade response to you.

The server's response's Sec-WebSocket-Accept header will have a value computed based upon the specified key.

Sec-WebSocket-Protocol

The Sec-WebSocket-Protocol header specifies one or more WebSocket protocols that you wish to use, in order of preference. The first one that is supported by the server will be selected and returned by the server in a Sec-WebSocket-Protocol header included in the response. You can use this more than once in the header, as well; the result is the same as if you used a comma-delineated list of subprotocol identifiers in a single header.

Sec-WebSocket-Protocol: subprotocols
subprotocols
A comma-separated list of subprotocol names, in the order of preference. The subprotocols may be selected from the IANA WebSocket Subprotocol Name Registry or may be a custom name jointly understood by the client and the server.

Sec-WebSocket-Version

Request header

Specifies the WebSocket protocol version the client wishes to use, so the server can confirm whether or not that version is supported on its end.

Sec-WebSocket-Version: version
version
The WebSocket protocol version the client wishes to use when communicating with the server. This number should be the most recent version possible listed in the IANA WebSocket Version Number Registry. The most recent final version of the WebSocket protocol is version 13.
Response header

If the server can't communicate using the specified version of the WebSocket protocol, it will respond with an error (such as 426 Upgrade Required) that includes in its headers a Sec-WebSocket-Version header with a comma-separated list of the supported protocol versions. If the server does support the requested protocol version, no Sec-WebSocket-Version header is included in the response.

Sec-WebSocket-Version: supportedVersions
supportedVersions
A comma-delineated list of the WebSocket protocol versions supported by the server.

Response-only headers

The response from the server may include these.

Sec-WebSocket-Accept

Included in the response message from the server during the opening handshake process when the server is willing to initiate a WebSocket connection. It will appear no more than once in the response headers.

Sec-WebSocket-Accept: hash
hash
If a Sec-WebSocket-Key header was provided, the value of this header is computed by taking the value of the key, concatenating the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" to it, taking the SHA-1 hash of that concatenated string, resulting in a 20-byte value. That value is then base64 encoded to obtain the value of this property.

References