--- title: Protocol upgrade mechanism slug: Web/HTTP/Protocol_upgrade_mechanism translation_of: Web/HTTP/Protocol_upgrade_mechanism ---
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) {{HTTPHeader("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.
Il campo d'intestazione(Header) {{HTTPHeader("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) {{HTTPHeader("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 {{anch("Upgrading to a WebSocket connection")}} per maggiori dettagli.
Se il server decide di aggiornare la connessione, restituisce lo stato di risposta {{HTTPStatus(101, "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 {{HTTPStatus(200, "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.
Qui esaminiamo i casi d'uso più comuni per l' {{HTTPHeader("Upgrade")}} del header.
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 {{domxref("WebSocket.WebSocket", "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 {{HTTPHeader("Upgrade")}} e {{HTTPHeader("Connection")}} headers, come segue:
Connection: Upgrade Upgrade: websocket
Le seguenti intestazioni sono coinvolte nel processo di aggiornamento del WebSocket. Oltre al {{HTTPHeader("Upgrade")}} e {{HTTPHeader("Connection")}} headers, the rest are generally optional or handled for you by the browser and server when they're talking to each other.
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
For example:
Sec-WebSocket-Extensions: superspeed, colormode; depth=16
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 {{domxref("XMLHttpRequest.setRequestHeader()")}}.
Sec-WebSocket-Key: key
key
The server's response's {{HTTPHeader("Sec-WebSocket-Accept")}} header will have a value computed based upon the specified key
.
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
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
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
The response from the server may include these.
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