7. Instradamento dei Messaggi HTTP (Routing HTTP Messages)

L'instradamento dei messaggi di richiesta HTTP è determinato da ciascun client in base alla risorsa di destinazione, alla configurazione del proxy del client e alla creazione o al riutilizzo di una connessione in entrata. L'instradamento della risposta corrispondente segue la stessa catena di connessione verso il client.

7.1. Determinazione della Risorsa di Destinazione (Determining the Target Resource)

Sebbene HTTP sia utilizzato in un'ampia varietà di applicazioni, la maggior parte dei client si affida allo stesso meccanismo di identificazione delle risorse e alle stesse tecniche di configurazione dei browser Web generici. Anche quando le opzioni di comunicazione sono codificate in modo rigido nella configurazione di un client, possiamo pensare al loro effetto combinato come un riferimento URI (Sezione 4.1).

Un riferimento URI viene risolto nella sua forma assoluta al fine di ottenere l'「URI di destinazione」(target URI). L'URI di destinazione esclude il componente frammento del riferimento, se presente, poiché gli identificatori di frammento sono riservati per l'elaborazione lato client ([URI], Sezione 3.5).

Per eseguire un'azione su una「risorsa di destinazione」(target resource), il client invia un messaggio di richiesta contenente componenti sufficienti del suo URI di destinazione analizzato per consentire ai destinatari di identificare quella stessa risorsa. Per ragioni storiche, i componenti dell'URI di destinazione analizzati, collettivamente denominati「destinazione della richiesta」(request target), vengono inviati all'interno dei dati di controllo del messaggio e del campo di intestazione Host (Sezione 7.2).

Ci sono due casi insoliti per i quali i componenti della destinazione della richiesta sono in una forma specifica del metodo:

• Per CONNECT (Sezione 9.3.6), la destinazione della richiesta è il nome host e il numero di porta della destinazione del tunnel, separati da due punti.

• Per OPTIONS (Sezione 9.3.7), la destinazione della richiesta può essere un singolo asterisco ("*").

Consultare le rispettive definizioni del metodo per i dettagli. Queste forme NON DEVONO (MUST NOT) essere utilizzate con altri metodi.

Alla ricezione della richiesta di un client, un server ricostruisce l'URI di destinazione dai componenti ricevuti in conformità con la loro configurazione locale e il contesto della connessione in entrata. Questa ricostruzione è specifica per ciascuna versione principale del protocollo. Ad esempio, la Sezione 3.3 di [HTTP/1.1] definisce come un server determina l'URI di destinazione di una richiesta HTTP/1.1.

Nota: Le specifiche precedenti definivano l'URI di destinazione ricomposto come un concetto distinto, l'「URI di richiesta effettivo」(effective request URI).

7.2. Host e :authority

Il campo di intestazione「Host」in una richiesta fornisce le informazioni sull'host e la porta dall'URI di destinazione, consentendo al server di origine di distinguere tra le risorse mentre serve le richieste per più nomi host.

In HTTP/2 [HTTP/2] e HTTP/3 [HTTP/3], il campo di intestazione Host è, in alcuni casi, sostituito dal campo pseudo-intestazione「:authority」dei dati di controllo di una richiesta.

Host = uri-host [ ":" port ] ; Sezione 4

Le informazioni di autorità dell'URI di destinazione sono cruciali per la gestione di una richiesta. Un agente utente DEVE (MUST) generare un campo di intestazione Host in una richiesta a meno che non invii tali informazioni come campo pseudo-intestazione「:authority」. Un agente utente che invia Host DOVREBBE (SHOULD) inviarlo come primo campo nella sezione di intestazione di una richiesta.

Ad esempio, una richiesta GET al server di origine per http://www.example.org/pub/WWW/ inizierebbe con:

GET /pub/WWW/ HTTP/1.1
Host: www.example.org

Poiché le informazioni sull'host e la porta fungono da meccanismo di instradamento a livello di applicazione, sono un bersaglio frequente per malware che cercano di avvelenare una cache condivisa o reindirizzare una richiesta a un server non intenzionale. Un proxy di intercettazione è particolarmente vulnerabile se si affida alle informazioni sull'host e la porta per reindirizzare le richieste a server interni, o per l'uso come chiave di cache in una cache condivisa, senza prima verificare che la connessione intercettata stia puntando a un indirizzo IP valido per quell'host.

7.3. Instradamento delle Richieste in Entrata (Routing Inbound Requests)

Una volta determinati l'URI di destinazione e la sua origine, un client decide se è necessaria una richiesta di rete per realizzare la semantica desiderata e, in caso affermativo, dove tale richiesta deve essere diretta.

7.3.1. Verso una Cache (To a Cache)

Se il client ha una cache [CACHING] e la richiesta può essere soddisfatta da essa, allora la richiesta è solitamente diretta lì per prima.

7.3.2. Verso un Proxy (To a Proxy)

Se la richiesta non è soddisfatta da una cache, allora un client tipico controllerà la sua configurazione per determinare se deve essere utilizzato un proxy per soddisfare la richiesta. La configurazione del proxy è dipendente dall'implementazione, ma spesso si basa sulla corrispondenza del prefisso URI, sulla corrispondenza selettiva dell'autorità, o entrambe, e il proxy stesso è solitamente identificato da un URI「http」o「https」.

Se un proxy「http」o「https」è applicabile, il client si connette in entrata stabilendo (o riutilizzando) una connessione a quel proxy e quindi inviandogli un messaggio di richiesta HTTP contenente una destinazione di richiesta che corrisponde all'URI di destinazione del client.

7.3.3. Verso l'Origine (To the Origin)

Se nessun proxy è applicabile, un client tipico invocherà una routine di gestione (specifica per lo schema dell'URI di destinazione) per ottenere l'accesso alla risorsa identificata. Come ciò venga realizzato dipende dallo schema dell'URI di destinazione ed è definito dalla sua specifica associata.

La Sezione 4.3.2 definisce come ottenere l'accesso a una risorsa「http」stabilendo (o riutilizzando) una connessione in entrata al server di origine identificato e quindi inviandogli un messaggio di richiesta HTTP contenente una destinazione di richiesta che corrisponde all'URI di destinazione del client.

La Sezione 4.3.3 definisce come ottenere l'accesso a una risorsa「https」stabilendo (o riutilizzando) una connessione sicura in entrata a un server di origine che è autorevole per l'origine identificata e quindi inviandogli un messaggio di richiesta HTTP contenente una destinazione di richiesta che corrisponde all'URI di destinazione del client.

7.4. Rifiuto di Richieste Indirizzate Erroneamente (Rejecting Misdirected Requests)

Una volta che una richiesta è ricevuta da un server e analizzata sufficientemente per determinare il suo URI di destinazione, il server decide se elaborare la richiesta stessa, inoltrare la richiesta a un altro server, reindirizzare il client a una risorsa diversa, rispondere con un errore o interrompere la connessione. Questa decisione può essere influenzata da qualsiasi cosa riguardante la richiesta o il contesto della connessione, ma è specificamente diretta verso se il server è stato configurato per elaborare le richieste per quell'URI di destinazione e se il contesto della connessione è appropriato per quella richiesta.

Ad esempio, una richiesta potrebbe essere stata indirizzata erroneamente, deliberatamente o accidentalmente, in modo tale che le informazioni all'interno di un campo di intestazione Host ricevuto differiscano dall'host o dalla porta della connessione. Se la connessione proviene da un gateway attendibile, tale incoerenza potrebbe essere prevista; altrimenti, potrebbe indicare un tentativo di aggirare i filtri di sicurezza, ingannare il server a consegnare contenuti non pubblici o avvelenare una cache. Vedere la Sezione 17 per considerazioni di sicurezza riguardanti l'instradamento dei messaggi.

A meno che la connessione non provenga da un gateway attendibile, un server di origine DEVE (MUST) rifiutare una richiesta se non sono soddisfatti requisiti specifici dello schema per l'URI di destinazione. In particolare, una richiesta per una risorsa「https」DEVE (MUST) essere rifiutata a meno che non sia stata ricevuta su una connessione che è stata protetta tramite un certificato valido per l'origine di quell'URI di destinazione, come definito dalla Sezione 4.2.2.

Il codice di stato 421 (Misdirected Request) in una risposta indica che il server di origine ha rifiutato la richiesta perché sembra essere stata indirizzata erroneamente (Sezione 15.5.20).

7.5. Correlazione delle Risposte (Response Correlation)

Una connessione potrebbe essere utilizzata per più scambi richiesta/risposta. Il meccanismo utilizzato per correlare tra messaggi di richiesta e risposta dipende dalla versione; alcune versioni di HTTP utilizzano l'ordine implicito dei messaggi, mentre altre utilizzano un identificatore esplicito.

Tutte le risposte, indipendentemente dal codice di stato (comprese le risposte provvisorie) possono essere inviate in qualsiasi momento dopo la ricezione di una richiesta, anche se la richiesta non è ancora completa. Una risposta può completarsi prima che la sua richiesta corrispondente sia completa (Sezione 6.1). Allo stesso modo, i client non sono tenuti ad attendere un periodo di tempo specifico per una risposta. I client (compresi gli intermediari) potrebbero abbandonare una richiesta se la risposta non viene ricevuta entro un periodo di tempo ragionevole.

Un client che riceve una risposta mentre sta ancora inviando la richiesta associata DOVREBBE (SHOULD) continuare a inviare quella richiesta a meno che non riceva un'indicazione esplicita contraria (vedere, ad esempio, la Sezione 9.5 di [HTTP/1.1] e la Sezione 6.4 di [HTTP/2]).

7.6. Inoltro dei Messaggi (Message Forwarding)

Come descritto nella Sezione 3.7, gli intermediari possono svolgere una varietà di ruoli nell'elaborazione delle richieste e risposte HTTP. Alcuni intermediari vengono utilizzati per migliorare le prestazioni o la disponibilità. Altri vengono utilizzati per il controllo degli accessi o per filtrare i contenuti. Poiché un flusso HTTP ha caratteristiche simili a un'architettura pipe-and-filter, non ci sono limiti intrinseci all'entità in cui un intermediario può migliorare (o interferire) con entrambe le direzioni del flusso.

Gli intermediari dovrebbero inoltrare i messaggi anche quando gli elementi del protocollo non sono riconosciuti (ad es., nuovi metodi, codici di stato o nomi di campo) poiché ciò preserva l'estensibilità per i destinatari a valle.

Un intermediario che non agisce come tunnel DEVE (MUST) implementare il campo di intestazione Connection, come specificato nella Sezione 7.6.1, ed escludere i campi dall'essere inoltrati che sono destinati solo alla connessione in entrata.

Un intermediario NON DEVE (MUST NOT) inoltrare un messaggio a se stesso a meno che non sia protetto da un loop di richieste infinito. In generale, un intermediario dovrebbe riconoscere i propri nomi di server, inclusi eventuali alias, variazioni locali o indirizzi IP letterali, e rispondere direttamente a tali richieste.

Un messaggio HTTP può essere analizzato come flusso per l'elaborazione incrementale o l'inoltro a valle. Tuttavia, i mittenti e i destinatari non possono fare affidamento sulla consegna incrementale di messaggi parziali, poiché alcune implementazioni memorizzeranno in buffer o ritarderanno l'inoltro dei messaggi per motivi di efficienza di rete, controlli di sicurezza o trasformazioni del contenuto.

7.6.1. Connection

Il campo di intestazione「Connection」consente al mittente di elencare le opzioni di controllo desiderate per la connessione corrente.

Connection        = #connection-option
connection-option = token

Le opzioni di connessione non sono sensibili alle maiuscole.

Quando un campo diverso da Connection viene utilizzato per fornire informazioni di controllo per o sulla connessione corrente, il mittente DEVE (MUST) elencare il nome del campo corrispondente all'interno del campo di intestazione Connection. Si noti che alcune versioni di HTTP vietano l'uso di campi per tali informazioni e pertanto non consentono il campo Connection.

Gli intermediari DEVONO (MUST) analizzare un campo di intestazione Connection ricevuto prima che un messaggio venga inoltrato e, per ciascuna connection-option in questo campo, rimuovere qualsiasi campo di intestazione o trailer dal messaggio con lo stesso nome della connection-option, e quindi rimuovere il campo di intestazione Connection stesso (o sostituirlo con le proprie opzioni di controllo dell'intermediario per il messaggio inoltrato).

Pertanto, il campo di intestazione Connection fornisce un modo dichiarativo di distinguere i campi che sono destinati solo al destinatario immediato (「hop-by-hop」) da quei campi che sono destinati a tutti i destinatari sulla catena (「end-to-end」), consentendo al messaggio di essere auto-descrittivo e permettendo alle future estensioni specifiche della connessione di essere distribuite senza timore che vengano inoltrate ciecamente da intermediari più vecchi.

Inoltre, gli intermediari DOVREBBERO (SHOULD) rimuovere o sostituire i campi che è noto richiedere la rimozione prima dell'inoltro, indipendentemente dal fatto che appaiano o meno come connection-option, dopo aver applicato la semantica di tali campi. Questo include ma non è limitato a:

• Proxy-Connection (Appendice C.2.2 di [HTTP/1.1])
• Keep-Alive (Sezione 19.7.1 di [RFC2068])
• TE (Sezione 10.1.4)
• Transfer-Encoding (Sezione 6.1 di [HTTP/1.1])
• Upgrade (Sezione 7.8)

Un mittente NON DEVE (MUST NOT) inviare un'opzione di connessione corrispondente a un campo che è destinato a tutti i destinatari del contenuto. Ad esempio, Cache-Control non è mai appropriato come opzione di connessione (Sezione 5.2 di [CACHING]).

Le opzioni di connessione non corrispondono sempre a un campo presente nel messaggio, poiché un campo specifico della connessione potrebbe non essere necessario se non ci sono parametri associati a un'opzione di connessione. Al contrario, un campo specifico della connessione ricevuto senza un'opzione di connessione corrispondente indica solitamente che il campo è stato inoltrato in modo improprio da un intermediario e dovrebbe essere ignorato dal destinatario.

Quando si definisce una nuova opzione di connessione che non corrisponde a un campo, gli autori delle specifiche dovrebbero comunque riservare il nome del campo corrispondente per evitare collisioni successive. Tali nomi di campo riservati sono registrati nel「Registro dei Nomi di Campo del Protocollo di Trasferimento Ipertestuale (HTTP)」(Sezione 16.3.1).

7.6.2. Max-Forwards

Il campo di intestazione「Max-Forwards」fornisce un meccanismo con i metodi di richiesta TRACE (Sezione 9.3.8) e OPTIONS (Sezione 9.3.7) per limitare il numero di volte che la richiesta viene inoltrata dai proxy. Questo può essere utile quando il client sta tentando di tracciare una richiesta che sembra fallire o ciclare a metà catena.

Max-Forwards = 1*DIGIT

Il valore Max-Forwards è un intero decimale che indica il numero rimanente di volte che questo messaggio di richiesta può essere inoltrato.

Ogni intermediario che riceve una richiesta TRACE o OPTIONS contenente un campo di intestazione Max-Forwards DEVE (MUST) controllare e aggiornare il suo valore prima di inoltrare la richiesta. Se il valore ricevuto è zero (0), l'intermediario NON DEVE (MUST NOT) inoltrare la richiesta; invece, l'intermediario DEVE (MUST) rispondere come destinatario finale. Se il valore Max-Forwards ricevuto è maggiore di zero, l'intermediario DEVE (MUST) generare un campo Max-Forwards aggiornato nel messaggio inoltrato con un valore di campo che è il minore tra a) il valore ricevuto decrementato di uno (1) o b) il valore massimo supportato dal destinatario per Max-Forwards.

Un destinatario PUÒ (MAY) ignorare un campo di intestazione Max-Forwards ricevuto con altri metodi di richiesta.

7.6.3. Via

Il campo di intestazione「Via」indica la presenza di protocolli e destinatari intermedi tra l'agente utente e il server (sulle richieste) o tra il server di origine e il client (sulle risposte), simile al campo di intestazione「Received」nella posta elettronica (Sezione 3.6.7 di [RFC5322]). Via può essere utilizzato per tracciare gli inoltri dei messaggi, evitare loop di richieste e identificare le capacità del protocollo dei mittenti lungo la catena richiesta/risposta.

Via = #( received-protocol RWS received-by [ RWS comment ] )

received-protocol = [ protocol-name "/" ] protocol-version
                  ; vedere Sezione 7.8
received-by       = pseudonym [ ":" port ]
pseudonym         = token

Ogni membro del valore del campo Via rappresenta un proxy o gateway che ha inoltrato il messaggio. Ogni intermediario aggiunge le proprie informazioni su come è stato ricevuto il messaggio, in modo tale che il risultato finale sia ordinato secondo la sequenza dei destinatari di inoltro.

Un proxy DEVE (MUST) inviare un campo di intestazione Via appropriato, come descritto di seguito, in ogni messaggio che inoltra. Un gateway HTTP-to-HTTP DEVE (MUST) inviare un campo di intestazione Via appropriato in ogni messaggio di richiesta in entrata e PUÒ (MAY) inviare un campo di intestazione Via nei messaggi di risposta inoltrati.

Per ogni intermediario, il received-protocol indica il protocollo e la versione del protocollo utilizzati dal mittente a monte del messaggio. Pertanto, il valore del campo Via registra le capacità del protocollo pubblicizzate della catena richiesta/risposta in modo tale che rimangano visibili ai destinatari a valle; questo può essere utile per determinare quali funzionalità non retrocompatibili potrebbero essere sicure da utilizzare nella risposta, o in una richiesta successiva, come descritto nella Sezione 2.5. Per brevità, il protocol-name viene omesso quando il protocollo ricevuto è HTTP.

La porzione received-by è normalmente l'host e il numero di porta opzionale di un server o client destinatario che successivamente ha inoltrato il messaggio. Tuttavia, se l'host reale è considerato informazione sensibile, un mittente PUÒ (MAY) sostituirlo con uno pseudonimo. Se una porta non è fornita, un destinatario PUÒ (MAY) interpretare ciò come significare che è stata ricevuta sulla porta predefinita, se presente, per il received-protocol.

Un mittente PUÒ (MAY) generare commenti per identificare il software di ciascun destinatario, in modo analogo ai campi di intestazione User-Agent e Server. Tuttavia, i commenti in Via sono facoltativi e un destinatario PUÒ (MAY) rimuoverli prima di inoltrare il messaggio.

Ad esempio, un messaggio di richiesta potrebbe essere inviato da un agente utente HTTP/1.0 a un proxy interno con nome in codice「fred」, che utilizza HTTP/1.1 per inoltrare la richiesta a un proxy pubblico presso p.example.net, che completa la richiesta inoltrando la al server di origine presso www.example.com. La richiesta ricevuta da www.example.com avrebbe quindi il seguente campo di intestazione Via:

Via: 1.0 fred, 1.1 p.example.net

Un intermediario utilizzato come portale attraverso un firewall di rete NON DOVREBBE (SHOULD NOT) inoltrare i nomi e le porte degli host all'interno della regione del firewall a meno che non sia esplicitamente abilitato a farlo. Se non abilitato, tale intermediario DOVREBBE (SHOULD) sostituire ciascun host received-by di qualsiasi host dietro il firewall con uno pseudonimo appropriato per quell'host.

Un intermediario PUÒ (MAY) combinare una sottosequenza ordinata di membri dell'elenco del campo di intestazione Via in un singolo membro se le voci hanno valori received-protocol identici. Ad esempio,

Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy

potrebbe essere ridotto a

Via: 1.0 ricky, 1.1 mertz, 1.0 lucy

Un mittente NON DOVREBBE (SHOULD NOT) combinare più membri dell'elenco a meno che non siano tutti sotto lo stesso controllo organizzativo e gli host non siano già stati sostituiti da pseudonimi. Un mittente NON DEVE (MUST NOT) combinare membri che hanno valori received-protocol diversi.

7.7. Trasformazioni dei Messaggi (Message Transformations)

Alcuni intermediari includono funzionalità per trasformare i messaggi e il loro contenuto. Un proxy potrebbe, ad esempio, convertire tra formati di immagine per risparmiare spazio nella cache o per ridurre la quantità di traffico su un collegamento lento. Tuttavia, potrebbero verificarsi problemi operativi quando queste trasformazioni vengono applicate a contenuti destinati ad applicazioni critiche, come l'imaging medico o l'analisi di dati scientifici, in particolare quando vengono utilizzati controlli di integrità o firme digitali per garantire che il contenuto ricevuto sia identico all'originale.

Un proxy HTTP-to-HTTP è chiamato「proxy di trasformazione」(transforming proxy) se è progettato o configurato per modificare i messaggi in modo semanticamente significativo (cioè, modifiche, oltre a quelle richieste dalla normale elaborazione HTTP, che cambiano il messaggio in un modo che sarebbe significativo per il mittente originale o potenzialmente significativo per i destinatari a valle). Ad esempio, un proxy di trasformazione potrebbe agire come server di annotazioni condiviso (modificando le risposte per includere riferimenti a un database di annotazioni locali), un filtro malware, un transcodificatore di formato o un filtro per la privacy. Tali trasformazioni si presumono desiderate dal client (o dall'organizzazione client) che ha scelto il proxy.

Se un proxy riceve un URI di destinazione con un nome host che non è un nome di dominio completamente qualificato, PUÒ (MAY) aggiungere il proprio dominio al nome host ricevuto quando inoltra la richiesta. Un proxy NON DEVE (MUST NOT) modificare il nome host se l'URI di destinazione contiene un nome di dominio completamente qualificato.

Un proxy NON DEVE (MUST NOT) modificare le parti「absolute-path」e「query」dell'URI di destinazione ricevuto quando lo inoltra al server in entrata successivo, tranne come richiesto da quel protocollo di inoltro. Ad esempio, un proxy che inoltra una richiesta a un server di origine tramite HTTP/1.1 sostituirà un percorso vuoto con「/」(Sezione 3.2.1 di [HTTP/1.1]) o「*」(Sezione 3.2.4 di [HTTP/1.1]), a seconda del metodo di richiesta.

Un proxy NON DEVE (MUST NOT) trasformare il contenuto (Sezione 6.4) di un messaggio di risposta che contiene una direttiva di cache no-transform (Sezione 5.2.2.6 di [CACHING]). Si noti che questo non si applica alle trasformazioni di messaggi che non modificano il contenuto, come l'aggiunta o la rimozione di codifiche di trasferimento (Sezione 7 di [HTTP/1.1]).

Un proxy PUÒ (MAY) trasformare il contenuto di un messaggio che non contiene una direttiva di cache no-transform. Un proxy che trasforma il contenuto di una risposta 200 (OK) può informare i destinatari a valle che è stata applicata una trasformazione modificando il codice di stato della risposta a 203 (Non-Authoritative Information) (Sezione 15.3.4).

Un proxy NON DOVREBBE (SHOULD NOT) modificare i campi di intestazione che forniscono informazioni sugli endpoint della catena di comunicazione, sullo stato della risorsa o sulla rappresentazione selezionata (diversa dal contenuto) a meno che la definizione del campo non consenta specificamente tale modifica o la modifica sia ritenuta necessaria per motivi di privacy o sicurezza.

7.8. Upgrade

Il campo di intestazione「Upgrade」è inteso a fornire un meccanismo semplice per la transizione da HTTP/1.1 a qualche altro protocollo sulla stessa connessione.

Un client PUÒ (MAY) inviare un elenco di nomi di protocollo nel campo di intestazione Upgrade di una richiesta per invitare il server a passare a uno o più dei protocolli nominati, in ordine di preferenza decrescente, prima di inviare la risposta finale. Un server PUÒ (MAY) ignorare un campo di intestazione Upgrade ricevuto se desidera continuare a utilizzare il protocollo corrente su quella connessione. Upgrade non può essere utilizzato per insistere su un cambio di protocollo.

Upgrade          = #protocol

protocol         = protocol-name ["/" protocol-version]
protocol-name    = token
protocol-version = token

Sebbene i nomi di protocollo siano registrati con una maiuscola preferita, i destinatari DOVREBBERO (SHOULD) utilizzare un confronto senza distinzione tra maiuscole e minuscole quando abbinano ciascun protocol-name ai protocolli supportati.

Un server che invia una risposta 101 (Switching Protocols) DEVE (MUST) inviare un campo di intestazione Upgrade per indicare il/i nuovo/i protocollo/i a cui la connessione sta passando; se vengono commutati più livelli di protocollo, il mittente DEVE (MUST) elencare i protocolli in ordine ascendente di livello. Un server NON DEVE (MUST NOT) passare a un protocollo che non è stato indicato dal client nel campo di intestazione Upgrade della richiesta corrispondente. Un server PUÒ (MAY) scegliere di ignorare l'ordine di preferenza indicato dal client e selezionare il/i nuovo/i protocollo/i in base ad altri fattori, come la natura della richiesta o il carico corrente del server.

Un server che invia una risposta 426 (Upgrade Required) DEVE (MUST) inviare un campo di intestazione Upgrade per indicare i protocolli accettabili, in ordine di preferenza decrescente.

Un server PUÒ (MAY) inviare un campo di intestazione Upgrade in qualsiasi altra risposta per pubblicizzare che implementa il supporto per l'aggiornamento ai protocolli elencati, in ordine di preferenza decrescente, quando appropriato per una richiesta futura.

Quello che segue è un esempio ipotetico inviato da un client:

GET /hello HTTP/1.1
Host: www.example.com
Connection: upgrade
Upgrade: websocket, IRC/6.9, RTA/x11

Le capacità e la natura della comunicazione a livello di applicazione dopo il cambio di protocollo dipendono interamente dal/dai nuovo/i protocollo/i scelto/i. Tuttavia, immediatamente dopo l'invio della risposta 101 (Switching Protocols), il server dovrebbe continuare a rispondere alla richiesta originale come se avesse ricevuto il suo equivalente nel nuovo protocollo (cioè, il server ha ancora una richiesta in sospeso da soddisfare dopo il cambio di protocollo, ed è previsto che lo faccia senza richiedere che la richiesta sia ripetuta).

Ad esempio, se il campo di intestazione Upgrade viene ricevuto in una richiesta GET e il server decide di cambiare protocollo, risponde prima con un messaggio 101 (Switching Protocols) in HTTP/1.1 e quindi segue immediatamente con l'equivalente del nuovo protocollo di una risposta a un GET sulla risorsa di destinazione. Ciò consente di aggiornare una connessione a protocolli con la stessa semantica di HTTP senza il costo di latenza di un ulteriore round trip. Un server NON DEVE (MUST NOT) cambiare protocollo a meno che la semantica del messaggio ricevuto possa essere onorata dal nuovo protocollo; una richiesta OPTIONS può essere onorata da qualsiasi protocollo.

Quello che segue è un esempio di risposta alla richiesta ipotetica sopra:

HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: websocket

[... il flusso di dati passa a websocket con una risposta appropriata
(come definito dal nuovo protocollo) alla richiesta「GET /hello」...]

Un mittente di Upgrade DEVE (MUST) inviare anche un'opzione di connessione「Upgrade」nel campo di intestazione Connection (Sezione 7.6.1) per informare gli intermediari di non inoltrare questo campo. Un server che riceve un campo di intestazione Upgrade in una richiesta HTTP/1.0 DEVE (MUST) ignorare quel campo Upgrade.

Un client non può iniziare a utilizzare un protocollo aggiornato sulla connessione finché non ha inviato completamente il messaggio di richiesta (cioè, il client non può cambiare il protocollo che sta inviando a metà di un messaggio). Se un server riceve sia un campo di intestazione Upgrade che un campo di intestazione Expect con l'aspettativa「100-continue」(Sezione 10.1.1), il server DEVE (MUST) inviare una risposta 100 (Continue) prima di inviare una risposta 101 (Switching Protocols).

Il campo di intestazione Upgrade si applica solo al cambio di protocolli sopra la connessione esistente; non può essere utilizzato per cambiare il protocollo di connessione (trasporto) sottostante, né per commutare la comunicazione esistente a una connessione diversa. Per questi scopi, è più appropriato utilizzare una risposta 3xx (Redirection) (Sezione 15.4).

Questa specifica definisce solo il nome di protocollo「HTTP」per l'uso da parte della famiglia di protocolli di trasferimento ipertestuale, come definito dalle regole di versione HTTP della Sezione 2.5 e dagli aggiornamenti futuri di questa specifica. Nomi di protocollo aggiuntivi dovrebbero essere registrati utilizzando la procedura di registrazione definita nella Sezione 16.7.