8. Esprimere la Semantica HTTP in HTTP/2

HTTP/2 è progettato per essere il più compatibile possibile con gli usi attuali di HTTP. Ciò significa che, dal punto di vista dell'applicazione, le caratteristiche del protocollo rimangono in gran parte invariate. Per ottenere ciò, tutte le semantiche di richiesta e risposta sono preservate attraverso i meccanismi in HTTP/1.1 [HTTP], sebbene la sintassi di trasmissione di tali semantiche sia cambiata.

Pertanto, la specifica e i requisiti di HTTP [HTTP], semantica e sintassi, così come le estensioni come [COOKIES], si applicano a HTTP/2. Le restrizioni e i requisiti aggiuntivi descritti in questa sezione sono limitati a quelli necessari per una implementazione riuscita di HTTP/2, che riguardano il formato wire di HTTP o che, in assenza di definizione aggiuntiva in HTTP/2, risulterebbero in ambiguità.

8.1. Inquadramento dei Messaggi HTTP

Un messaggio HTTP (richiesta o risposta) consiste di:

1. solo per una risposta, zero o più frame HEADERS (ciascuno seguito da zero o più frame CONTINUATION) contenenti gli header del messaggio delle risposte HTTP informative (1xx) (vedere Sezione 15 di [HTTP]), e/o

2. un frame HEADERS (seguito da zero o più frame CONTINUATION) contenente gli header del messaggio (vedere Sezione 6.3 di [HTTP]), e

3. zero o più frame DATA contenenti il contenuto del messaggio (vedere Sezione 6.4 di [HTTP]), e

4. opzionalmente, un frame HEADERS (seguito da zero o più frame CONTINUATION) contenente la sezione di campo della parte trailer (vedere Sezione 6.5 di [HTTP]).

L'ultimo frame nella sequenza porta un flag END_STREAM, notando che un frame HEADERS che porta il flag END_STREAM può essere seguito da frame CONTINUATION che trasportano qualsiasi porzione rimanente del blocco di header. Altri frame (da qualsiasi stream) NON DEVONO apparire tra il frame HEADERS e eventuali frame CONTINUATION che potrebbero seguire.

HTTP/2 utilizza frame DATA per trasportare il contenuto del messaggio. La codifica di trasferimento [CHUNKED] (definita nella Sezione 7.1 di [HTTP]) NON DEVE essere utilizzata con HTTP/2.

I campi trailer sono trasportati in una sezione di campo; vedere Sezione 8.2. Non esiste un nome di sezione di campo definito per i campi trailer perché tutti i campi trailer sono codificati nella stessa sezione di campo in HTTP/2. Non esiste un ordine definito tra le righe di campo; vedere Sezione 8.2.1. Infine, i campi trailer non includono campi pseudo-header (vedere Sezione 8.3).

Una richiesta o risposta HTTP è malformata se è una delle seguenti:

• Contiene una riga di campo con un nome di campo non valido (vedere Sezione 5.1 di [HTTP]), una riga di campo con un valore di riga di campo non valido (vedere Sezione 5.5 di [HTTP]), o un campo pseudo-header che non è consentito apparire in quel contesto (vedere Sezione 8.3),

• Omette un campo pseudo-header che è richiesto per quel tipo di messaggio (vedere Sezione 8.3),

• Contiene caratteri maiuscoli nei nomi delle righe di campo, o

• Contiene un valore di campo Content-Length non valido.

La gestione degli errori per gli stream è descritta in Sezione 8.1.1.

Oltre alle parti obbligatorie di un messaggio, le informazioni PRIORITY possono essere presenti nei frame HEADERS. Vedere Sezione 5.3 per maggiori informazioni.

La ricezione di un frame HEADERS contenente un blocco di campo non valido risulta in un errore di stream (vedere Sezione 5.4.2).

8.1.1. Messaggi Malformati

Un messaggio malformato è un messaggio che è altrimenti una sequenza valida di frame ma è non valido a causa della presenza di campi proibiti, dell'assenza di campi richiesti, o di valori di campo non validi. Un peer che rileva una richiesta o risposta malformata DEVE rispondere con un errore di stream (vedere Sezione 5.4.2). Per le richieste malformate, un server PUÒ inviare una risposta HTTP prima di chiudere o reimpostare lo stream. I client NON DEVONO accettare una risposta malformata. Si noti che questi requisiti sono destinati a proteggere contro diversi tipi di attacchi comuni; sono deliberatamente rigorosi perché essere permissivi può esporre le implementazioni a queste vulnerabilità.

8.2. Campi HTTP

I nomi e i valori dei campi HTTP sono sequenze di ottetti e sono utilizzati con la stessa codifica utilizzata in HTTP/1.x (vedere Sezione 5.1 di [HTTP]). Tuttavia, i nomi dei campi DEVONO essere convertiti in minuscolo prima della loro codifica in HTTP/2. Una richiesta o risposta contenente caratteri maiuscoli nei nomi dei campi DEVE essere trattata come malformata (Sezione 8.1.1).

HTTP/2 non utilizza il campo di intestazione Connection (vedere Sezione 7.6.1 di [HTTP]) per indicare campi specifici della connessione; in questo protocollo, i metadati specifici della connessione sono trasmessi con altri mezzi. Un endpoint NON DEVE generare un messaggio HTTP/2 contenente campi specifici della connessione; qualsiasi messaggio contenente campi specifici della connessione DEVE essere trattato come malformato (Sezione 8.1.1).

L'unica eccezione a questo è il campo di intestazione TE, che PUÒ essere presente in una richiesta HTTP/2; quando lo è, NON DEVE contenere alcun valore diverso da "trailers".

Ciò significa che un intermediario che trasforma un messaggio HTTP/1.x in HTTP/2 dovrà rimuovere tutti i campi nominati dal campo Connection, insieme al campo Connection stesso. Tali intermediari DOVREBBERO anche rimuovere altri campi specifici della connessione, come Keep-Alive, Proxy-Connection, Transfer-Encoding e Upgrade, anche se non sono nominati dal campo Connection.

|  Nota: HTTP/2 di proposito non supporta l'aggiornamento a un altro protocollo. I
|  metodi di handshake descritti in [Sezione 3](#3-starting-http2) sono ritenuti sufficienti
|  per negoziare l'uso di protocolli alternativi.

8.2.1. Validità dei Campi

I nomi dei campi sono validati secondo le regole nella Sezione 5.1 di [HTTP], ma convertiti in minuscolo prima della rappresentazione in HTTP/2.

Una sezione di campo compressa utilizzando [COMPRESSION] può contenere spazi bianchi come definito dalla produzione "optional whitespace" (OWS); gli spazi bianchi non fanno parte del campo; DEVONO essere rimossi durante la decompressione o prima di passare il messaggio a un contesto non-HTTP/2, come una connessione HTTP/1.1, o un'applicazione server HTTP generica.

I valori dei campi pseudo-header sono specificati in Sezione 8.3.

8.2.2. Campi di Intestazione Specifici della Connessione

HTTP/2 non utilizza il campo di intestazione Connection per indicare campi specifici della connessione; in questo protocollo, i metadati specifici della connessione sono trasmessi con altri mezzi. Un endpoint NON DEVE generare un messaggio contenente campi specifici della connessione; qualsiasi messaggio contenente campi specifici della connessione DEVE essere trattato come malformato (Sezione 8.1.1).

L'unica eccezione a questo è il campo di intestazione TE, che PUÒ essere presente in una richiesta HTTP/2, ma quando lo è, NON DEVE contenere alcun valore diverso da "trailers".

8.2.3. Compressione del Campo di Intestazione Cookie

Il campo di intestazione Cookie [COOKIES] utilizza un punto e virgola (";") per delimitare le coppie di cookie (o "briciole"). Questo campo di intestazione non segue le regole di lista (vedere Sezione 5.3 di [HTTP]) della separazione con virgola, il che può impedire alle coppie di cookie di essere compresse efficientemente. Poiché il campo di intestazione Cookie può spesso contenere una quantità relativamente grande di dati, questo può degradare significativamente l'efficienza della compressione.

Per consentire una migliore compressione, il campo di intestazione Cookie PUÒ essere suddiviso in campi di intestazione separati, ciascuno con una o più coppie di cookie. Se ci sono più campi di intestazione Cookie dopo la decompressione, questi DEVONO essere concatenati in una singola stringa di ottetti utilizzando il delimitatore a due ottetti di 0x3B, 0x20 (la stringa ASCII "; ") prima di essere passati in un contesto non-HTTP/2, come una connessione HTTP/1.1, o un'applicazione server HTTP generica.

Pertanto, le seguenti due liste di campi di intestazione Cookie sono semanticamente equivalenti.

cookie: a=b; c=d; e=f

cookie: a=b
cookie: c=d
cookie: e=f

8.3. Dati di Controllo HTTP

HTTP/2 utilizza campi pseudo-header speciali che iniziano con il carattere ':' (ASCII 0x3a) per trasmettere informazioni sulla richiesta o risposta che, in HTTP/1.x, erano trasportate nella riga di inizio del messaggio. I campi pseudo-header non sono campi HTTP. Gli endpoint NON DEVONO generare campi pseudo-header diversi da quelli definiti in questo documento.

I campi pseudo-header sono validi solo nella sezione di campo di un frame HEADERS e PUSH_PROMISE. Tuttavia, una sezione di campo che trasporta campi trailer NON DEVE contenere campi pseudo-header; una sezione di campo della parte trailer contenente campi pseudo-header DEVE essere trattata come malformata (Sezione 8.1.1).

I campi pseudo-header iniziano con un carattere ':' (ASCII 0x3a). I loro nomi sono nomi di campo che consistono solo di questo prefisso; i due punti non fanno parte del nome del campo. I due punti non fanno parte del set di token utilizzato per i nomi dei campi (vedere Sezione 5.1 di [HTTP]).

Tutti i campi pseudo-header DEVONO apparire prima di tutti i campi regolari. Qualsiasi richiesta o risposta che contenga un campo pseudo-header che appare dopo un campo regolare DEVE essere trattata come malformata (Sezione 8.1.1).

Sono definiti i seguenti campi pseudo-header:

8.3.1. Campi Pseudo-Header di Richiesta

I seguenti campi pseudo-header sono definiti per le richieste HTTP/2:

• Il campo pseudo-header :method contiene il metodo HTTP (Sezione 9 di [HTTP]).

• Il campo pseudo-header :scheme contiene la parte schema dell'URI di destinazione (Sezione 3.1 di [URI]).

  Il :scheme non è limitato agli URI con schema "http" e "https". Un proxy o gateway può tradurre richieste per schemi non-HTTP, abilitando l'uso di HTTP per interagire con servizi non-HTTP.

  Vedere Sezione 8.5 per il metodo CONNECT, che omette il campo pseudo-header :scheme.

• Il campo pseudo-header :authority contiene la parte di autorità dell'URI di destinazione (Sezione 3.2 di [URI]). L'autorità NON DEVE includere il sottocomponente userinfo deprecato per gli URI con schema "http" o "https".

  Per garantire che la riga di richiesta HTTP/1.1 possa essere riprodotta accuratamente, questo campo pseudo-header DEVE essere omesso quando si traduce da una richiesta HTTP/1.1 che ha un target di richiesta in forma di origine o asterisco (vedere Sezione 3.2 di [HTTP]). I client che generano richieste HTTP/2 direttamente DEVONO utilizzare il campo pseudo-header :authority al posto del campo Host. Un intermediario che converte una richiesta HTTP/2 in HTTP/1.1 DEVE creare un campo Host se non è presente in una richiesta copiando il valore del campo pseudo-header :authority.

  Un server DOVREBBE trattare una richiesta come malformata se contiene una richiesta che ha sia il campo pseudo-header :authority sia il campo Host, se i valori dei campi non sono identici.

• Il campo pseudo-header :path contiene le parti di percorso e query dell'URI di destinazione (la produzione absolute-path e opzionalmente un carattere '?' seguito dalla produzione query (vedere Sezioni 3.3 e 3.4 di [URI])). Una richiesta in forma di asterisco include il valore '*' per il campo pseudo-header :path.

  Questo campo pseudo-header NON DEVE essere vuoto per gli URI "http" o "https"; gli URI "http" o "https" che non contengono un componente di percorso DEVONO includere un valore di '/', a meno che la richiesta non sia fatta in forma di asterisco, nel qual caso DEVE contenere un valore di '*'.

  Vedere Sezione 8.5 per il metodo CONNECT, che omette il campo pseudo-header :path.

Tutte le richieste HTTP/2 DEVONO includere esattamente un valore valido per i campi pseudo-header :method e :scheme, a meno che non sia una richiesta CONNECT (Sezione 8.5).

Se il campo pseudo-header :scheme identifica uno schema che utilizza un'autorità (vedere Sezione 3.2 di [URI]), allora una richiesta HTTP/2 che non contiene il target di richiesta DEVE includere il campo :authority o il campo Host. Se questi campi sono assenti, il server che riceve la richiesta DOVREBBE rispondere con un codice di stato 400 (Bad Request) (vedere Sezione 15.5.1 di [HTTP]).

HTTP/2 non definisce un modo per trasportare l'identificatore di versione che è incluso nella riga di richiesta HTTP/1.1.

8.3.2. Campi Pseudo-Header di Risposta

Per le risposte HTTP/2, è definito un singolo campo pseudo-header :status che trasporta il campo del codice di stato HTTP (vedere Sezione 15 di [HTTP]). Questo campo pseudo-header DEVE essere incluso in tutte le risposte; altrimenti, la risposta è malformata (Sezione 8.1.1).

HTTP/2 non definisce un modo per trasportare la versione o la frase di motivazione che è inclusa in una riga di stato HTTP/1.1.

8.4. Push del Server

HTTP/2 consente a un server di inviare preventivamente (o "push") risposte a un client in associazione con una precedente richiesta iniziata dal client. Questo può essere utile quando il server sa che il client avrà bisogno di avere quelle risposte disponibili per elaborare completamente la risposta alla richiesta originale.

Una risposta push è sempre associata a una richiesta esplicita dal client. Il server invia un frame PUSH_PROMISE sullo stream di quella richiesta. Il frame PUSH_PROMISE include una sezione di campo che contiene un set completo di campi di richiesta che il server attribuisce alla richiesta.

Non c'è limite al numero di risposte che possono essere spinte da un server, a parte gli identificatori di stream disponibili su una singola connessione. Tuttavia, un client può limitare il numero di stream spinti contemporaneamente cambiando l'impostazione SETTINGS_MAX_CONCURRENT_STREAMS. Impostare questo valore a zero disabilita il push del server impedendo al server di creare gli stream necessari. Questo non impedisce a un server di inviare frame PUSH_PROMISE; i client devono reimpostare qualsiasi stream promesso non desiderato.

8.4.1. Richieste Push

Il push del server è semanticamente equivalente a un server che risponde a una richiesta; tuttavia, in questo caso, quella richiesta è anche inviata dal server, come frame PUSH_PROMISE.

Il frame PUSH_PROMISE include una sezione di campo che contiene un set completo di campi di richiesta che il server attribuisce alla richiesta. Non è possibile spingere una risposta a una richiesta che include un corpo di richiesta, eccetto nel caso in cui la connessione HTTP/2 sia stata iniziata su TLS (vedere [TLS13]).

Le richieste push DEVONO essere cacheable (vedere Sezione 9.2.3 di [HTTP]), DEVONO essere sicure (vedere Sezione 9.2.1 di [HTTP]), e NON DEVONO includere contenuto di richiesta. I client che ricevono una richiesta push che non è cacheable, non è sicura, o che include contenuto di richiesta DEVONO reimpostare lo stream promesso con un errore di stream (Sezione 5.4.2) di tipo PROTOCOL_ERROR.

I campi di richiesta push e i campi pseudo-header di richiesta DEVONO essere autorevoli (vedere Sezione 10.1). Il server DEVE includere un valore nel campo pseudo-header :authority per il quale il server è autorevole (vedere Sezione 10.1). Un client DEVE trattare una richiesta push che non è autorevole come un errore di stream (Sezione 5.4.2) di tipo PROTOCOL_ERROR.

Un client può segnalare che non desidera ricevere una risposta push inviando un RST_STREAM al server, riferendosi all'identificatore di stream promesso.

Un server DOVREBBE solo spingere risposte che crede che il client utilizzerà o da cui trarrà altrimenti beneficio. Il server DOVREBBE considerare il possibile contenuto della richiesta, tutti i campi di cache nella richiesta, il metodo della richiesta, e qualsiasi contenuto noto per essere gestito dal client (basato, ad esempio, sui Cookie ricevuti su richieste precedenti) quando decide cosa spingere.

8.4.2. Risposte Push

Dopo aver inviato un frame PUSH_PROMISE che fa riferimento allo stream promesso, il server può iniziare a consegnare la risposta push su uno stream utilizzando l'identificatore di stream promesso. Il server trasmette i campi di risposta iniziali utilizzando un frame HEADERS, utilizzando l'identificatore di stream promesso. Questo stream entra nello stato "half-closed (remote)" (Sezione 5.1). Il server DOVREBBE inviare la risposta che inizia il push prima di inviare il frame PUSH_PROMISE per evitare una condizione di gara.

Una volta che un client riceve un frame PUSH_PROMISE e sceglie di accettare la risposta push, il client NON DOVREBBE emettere richieste per la risposta promessa fino a dopo che lo stream promesso è stato chiuso.

Se il client determina, per qualsiasi motivo, che non desidera ricevere la risposta push dal server o se il server impiega troppo tempo per iniziare a inviare la risposta promessa, il client può inviare un frame RST_STREAM, utilizzando il codice CANCEL o REFUSED_STREAM e riferendosi all'identificatore di stream spinto.

Un client può utilizzare l'impostazione SETTINGS_MAX_CONCURRENT_STREAMS per limitare il numero di risposte che possono essere spinte contemporaneamente da un server. Annunciare un valore SETTINGS_MAX_CONCURRENT_STREAMS di zero disabilita il push del server impedendo al server di creare gli stream necessari. Questo non proibisce a un server di inviare frame PUSH_PROMISE; i client devono reimpostare qualsiasi stream promesso che non è desiderato.

8.5. Il Metodo CONNECT

In HTTP/1.x, il pseudo-metodo CONNECT (Sezione 9.3.6 di [HTTP]) è utilizzato per convertire una connessione HTTP in un tunnel verso un host remoto. CONNECT è utilizzato principalmente con proxy HTTP per stabilire una sessione TLS con un server di origine ai fini di interagire con risorse "https".

In HTTP/2, il metodo CONNECT è utilizzato per stabilire un tunnel su un host remoto per scopi simili.

Una richiesta CONNECT DEVE utilizzare i seguenti campi pseudo-header:

• Il campo pseudo-header :method è impostato a "CONNECT".
• Il campo pseudo-header :authority contiene l'host e la porta a cui connettersi (equivalente alla forma di autorità del target di richiesta di una richiesta CONNECT; vedere Sezione 3.2 di [HTTP]).

I campi pseudo-header :scheme e :path DEVONO essere omessi.

Una richiesta CONNECT NON DEVE contenere un campo di intestazione Content-Length o Transfer-Encoding. Qualsiasi richiesta CONNECT contenente questi campi è malformata (Sezione 8.1.1).

Uno stream che trasporta una richiesta CONNECT non è utilizzato per trasmettere richieste o risposte HTTP. Qualsiasi risposta CONNECT riuscita è utilizzata per notificare il client che lo stream è diventato un tunnel. Questo stream non viene chiuso ricevendo un frame DATA con il flag END_STREAM. Lo stream di richiesta CONNECT non viene chiuso ricevendo un frame DATA che porta il flag END_STREAM.

Un proxy rimuove tutti i campi di intestazione noti per essere specifici della connessione (come quelli definiti nella Sezione 7.6.1 di [HTTP]), quindi consente ai campi di intestazione di richiesta rimanenti di passare invariati sulla connessione al server.

Qualsiasi risposta 2xx (Successful) ricevuta dopo una richiesta CONNECT indica che il proxy ha stabilito una connessione all'host e alla porta richiesti e ha cambiato per fare il tunneling dello stream corrispondente.

Per qualsiasi altra risposta riuscita, non viene creato alcun tunnel.

Dopo che un tunnel riuscito è stabilito, il server DEVE inviare un singolo frame DATA (con il flag END_STREAM impostato) sullo stream del tunnel per chiudere immediatamente il tunnel. Il client DOVREBBE chiudere a metà il suo stream a entrambi gli endpoint dopo la chiusura del tunnel e quindi chiudere il suo stream dopo aver ricevuto il flag END_STREAM dal peer.

Un errore di connessione TCP è segnalato da entrambi gli endpoint utilizzando un frame RST_STREAM con un codice di errore. Un proxy tratta qualsiasi codice di errore che riceve come indicazione di un errore di stream (Sezione 5.4.2) che non è riuscito a completare con successo la richiesta CONNECT. Corrispondentemente, se un proxy rileva un errore con la connessione TCP che sta rappresentando per uno stream di richiesta CONNECT, invia un segnale al client nello stesso modo.

8.6. Il Campo di Intestazione Upgrade

HTTP/2 non supporta il codice di stato informativo 101 (Switching Protocols) (Sezione 15.2.2 di [HTTP]).

La semantica del campo di intestazione Upgrade è specifica al protocollo a cui eseguire l'aggiornamento. Il campo Upgrade in una connessione diretta (Sezione 9.1.1) si applica solo al prossimo hop. Pertanto, il campo Upgrade non è applicabile a HTTP/2.

Un'implementazione che desidera eseguire l'aggiornamento a un protocollo diverso su una connessione HTTP/2 DOVREBBE utilizzare [ALT-SVC].

8.7. Affidabilità della Richiesta

In generale, un client HTTP non è in grado di riprovare una richiesta non-idempotente quando si verifica un errore perché non esiste alcun mezzo per determinare la natura dell'errore. È possibile che sia avvenuta un'elaborazione del server prima dell'errore, il che potrebbe risultare in effetti indesiderati se la richiesta venisse ritentata.

Quando un server rifiuta uno stream di richiesta senza eseguire alcuna elaborazione dell'applicazione, la richiesta può essere considerata sicura da riprovare su una connessione diversa. Un server può indicare questo utilizzando il codice di errore REFUSED_STREAM (Sezione 7) su un frame RST_STREAM.

Un server NON DEVE utilizzare il codice di errore REFUSED_STREAM dopo aver eseguito l'elaborazione dell'applicazione. Questo perché l'utilizzo di REFUSED_STREAM indica che il server non ha eseguito alcuna elaborazione della richiesta, rendendola sicura da riprovare. Un codice di errore diverso DEVE essere utilizzato per le richieste che sono state elaborate dal server in qualche modo.

I client possono riprovare richieste che sono state rifiutate utilizzando REFUSED_STREAM, anche se la richiesta non è idempotente. Tuttavia, se il client sceglie di riprovare tale richiesta, DEVE assumere che il server potrebbe aver elaborato la richiesta prima di rifiutarla. Se il client ha riprovato una richiesta che non era idempotente, DOVREBBE includere un indicatore nelle richieste successive in modo che il server possa rilevare una richiesta riprovata.

Una richiesta PUSH_PROMISE che contiene contenuto non-cacheable non è riprovabile. Le richieste push che non sono cacheable o non sono sicure non sono consentite, come descritto in Sezione 8.4.1.

8.8. Esempi

Questa sezione mostra richieste e risposte HTTP/1.1, con illustrazioni di richieste e risposte HTTP/2 equivalenti. Una richiesta e risposta HTTP/2 utilizzano la sezione di intestazione compressa, che non è mostrata sopra il livello di frame HTTP/2.

8.8.1. Richiesta Semplice

Una richiesta GET HTTP/1.1 include campi di richiesta, un metodo e un target di richiesta.

GET /resource HTTP/1.1
Host: example.org
Accept: image/jpeg

La stessa richiesta è rappresentata utilizzando campi pseudo-header e inviata come sezione di campo in frame HEADERS in HTTP/2:

:method = GET
:scheme = https
:path = /resource
:authority = example.org
accept = image/jpeg

8.8.2. Risposta Semplice

Una risposta HTTP/1.1 semplice include un codice di stato, campi di risposta e contenuto di risposta:

HTTP/1.1 200 OK
Content-Type: image/jpeg
Content-Length: 123

{binary data}

In HTTP/2, il codice di stato è rappresentato utilizzando un campo pseudo-header:

:status = 200
content-type = image/jpeg
content-length = 123

{binary data}

8.8.3. Richiesta Complessa

Una richiesta POST HTTP/1.1 con campi opzionali:

POST /resource HTTP/1.1
Host: example.org
Content-Type: image/jpeg
Content-Length: 123

{binary data}

La stessa richiesta HTTP/2:

:method = POST
:scheme = https
:path = /resource
:authority = example.org
content-type = image/jpeg
content-length = 123

{binary data}

8.8.4. Risposta con Corpo

Una risposta HTTP/1.1, inclusi campi e un corpo di risposta:

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 552

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <h1>Example</h1>
    <p>This is an example page.</p>
  </body>
</html>

In HTTP/2, utilizzando una sezione di campo e frame DATA:

:status = 200
content-type = text/html; charset=utf-8
content-length = 552

<html>
  <head>
    <title>An Example Page</title>
  </head>
  <body>
    <h1>Example</h1>
    <p>This is an example page.</p>
  </body>
</html>

8.8.5. Risposte Informative

HTTP/2 supporta risposte informative (1xx) inviate utilizzando frame HEADERS, come definito nella Sezione 15 di [HTTP].

Ad esempio, una risposta 100 (Continue) può essere inviata prima di una risposta finale:

:status = 100

:status = 200
content-type = image/jpeg
content-length = 123

{binary data}

---

Capitolo 8 completato!

Riferimenti

• [HTTP] RFC 9110
• [COOKIES] RFC 6265
• [COMPRESSION] RFC 7541
• [URI] RFC 3986
• [TLS13] RFC 8446
• [ALT-SVC] RFC 7838