8. Expressing HTTP Semantics in HTTP/2 (Espressione della Semantica HTTP in HTTP/2)

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

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

8.1. HTTP Message Framing (Incorniciamento 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 di 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 di 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 trailer-part (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 portano qualsiasi porzione rimanente del blocco header. Altri frame (da qualsiasi stream) NON DEVONO verificarsi tra il frame HEADERS e qualsiasi frame CONTINUATION che potrebbe 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 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 ulteriori informazioni.

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

8.1.1. Malformed Messages (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 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 intesi a proteggere da diversi tipi di attacchi comuni; sono deliberatamente rigorosi perché essere permissivi può esporre le implementazioni a queste vulnerabilità.

8.2. HTTP Fields (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 di nome di campo maiuscoli DEVE essere trattata come malformata (Sezione 8.1.1).

HTTP/2 non utilizza il campo header Connection (vedere Sezione 7.6.1 di [HTTP]) per indicare campi specifici della connessione; in questo protocollo, i metadati specifici della connessione sono trasmessi attraverso 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 header TE, che PUÒ essere presente in una richiesta HTTP/2; quando è presente, 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 qualsiasi campo nominato 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 volutamente non supporta l'aggiornamento a un altro protocollo. | I metodi di handshake descritti in Sezione 3 sono considerati | sufficienti per negoziare l'uso di protocolli alternativi.

8.2.1. Field Validity (Validità dei Campi)

I nomi dei campi sono convalidati 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 definiti 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. Connection-Specific Header Fields (Campi Header Specifici della Connessione)

HTTP/2 non utilizza il campo header Connection per indicare campi specifici della connessione; in questo protocollo, i metadati specifici della connessione sono trasmessi attraverso 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 header TE, che PUÒ essere presente in una richiesta HTTP/2, ma quando è presente, NON DEVE contenere alcun valore diverso da "trailers".

8.2.3. Compressing the Cookie Header Field (Compressione del Campo Header Cookie)

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

Per consentire una migliore compressione, il campo header Cookie PUÒ essere diviso in campi header separati, ciascuno con una o più coppie di cookie. Se ci sono più campi header Cookie dopo la decompressione, questi DEVONO essere concatenati in una singola stringa di ottetti utilizzando il delimitatore di due ottetti 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 header Cookie sono semanticamente equivalenti.

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

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

8.3. HTTP Control Data (Dati di Controllo HTTP)

HTTP/2 utilizza speciali campi pseudo-header 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 trailer-part 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 di campo (vedere Sezione 5.1 di [HTTP]).

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

I seguenti campi pseudo-header sono definiti:

8.3.1. Request Pseudo-Header Fields (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 target (Sezione 3.1 di [URI]).

  Il :scheme non è limitato agli URI schematizzati "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 authority dell'URI target (Sezione 3.2 di [URI]). L'authority NON DEVE includere il sottocomponente userinfo deprecato per gli URI schematizzati "http" o "https".

  Per garantire che la riga di richiesta HTTP/1.1 possa essere riprodotta con precisione, 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 direttamente richieste HTTP/2 DEVONO utilizzare il campo pseudo-header :authority invece 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 sia il campo pseudo-header :authority che 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 target (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 effettuata 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 si tratti di una richiesta CONNECT (Sezione 8.5).

Se il campo pseudo-header :scheme identifica uno schema che utilizza un'authority (vedere Sezione 3.2 di [URI]), allora una richiesta HTTP/2 che non contiene il target della richiesta DEVE includere o 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 incluso nella riga di richiesta HTTP/1.1.

8.3.2. Response Pseudo-Header Fields (Campi Pseudo-Header di Risposta)

Per le risposte HTTP/2, è definito un singolo campo pseudo-header :status che trasporta il campo 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 motivo inclusa in una riga di stato HTTP/1.1.

8.4. Server Push (Push del Server)

HTTP/2 consente a un server di inviare preemptivamente (o "spingere") 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 spinta è 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 insieme 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 modificando 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. Push Requests (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 un frame PUSH_PROMISE.

Il frame PUSH_PROMISE include una sezione di campo che contiene un insieme 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, tranne nel caso in cui la connessione HTTP/2 sia stata iniziata su TLS (vedere [TLS13]).

Le richieste spinte DEVONO essere memorizzabili nella cache (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 spinta che non è memorizzabile nella cache, 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 spinta 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 spinta 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 spinta inviando un RST_STREAM al server, facendo riferimento all'identificatore di stream promesso.

Un server DOVREBBE spingere solo risposte che crede che il client utilizzerà o altrimenti beneficerà. Il server DOVREBBE considerare il possibile contenuto della richiesta, qualsiasi campo 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. Push Responses (Risposte Push)

Dopo aver inviato un frame PUSH_PROMISE che fa riferimento allo stream promesso, il server può iniziare a consegnare la risposta spinta 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 spinta, il client NON DOVREBBE emettere alcuna richiesta per la risposta promessa finché lo stream promesso non si è chiuso.

Se il client determina, per qualsiasi motivo, che non desidera ricevere la risposta spinta 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 facendo riferimento 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. Pubblicizzare 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 non desiderato.

8.5. The CONNECT Method (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 allo scopo 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 su "CONNECT".
• Il campo pseudo-header :authority contiene l'host e la porta a cui connettersi (equivalente alla forma di authority 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 header 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 di successo è utilizzata per notificare al client che lo stream è diventato un tunnel. Questo stream non è chiuso ricevendo un frame DATA con il flag END_STREAM. Lo stream di richiesta CONNECT non è chiuso ricevendo un frame DATA che porta il flag END_STREAM.

Un proxy rimuove qualsiasi campo header noto per essere specifico della connessione (come quelli definiti nella Sezione 7.6.1 di [HTTP]), quindi consente ai campi header di richiesta rimanenti di passare inalterati 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 iniziato a effettuare il tunneling dello stream corrispondente.

Per qualsiasi altra risposta di successo, non viene creato alcun tunnel.

Dopo che un tunnel di successo è stato 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 in entrambi gli endpoint dopo aver chiuso il 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 ricevuto 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 rappresenta per uno stream di richiesta CONNECT, invia un segnale al client nello stesso modo.

8.6. The Upgrade Header Field (Il Campo Header Upgrade)

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

La semantica del campo header Upgrade è specifica del protocollo a cui si sta effettuando l'upgrade. 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 effettuare l'upgrade a un protocollo diverso su una connessione HTTP/2 DOVREBBE utilizzare [ALT-SVC].

8.7. Request Reliability (Affidabilità della Richiesta)

In generale, un client HTTP non può riprovare una richiesta non-idempotente quando si verifica un errore perché non c'è modo di determinare la natura dell'errore. È possibile che si sia verificata un'elaborazione del server prima dell'errore, il che potrebbe provocare effetti indesiderati se la richiesta venisse ripetuta.

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 sulla richiesta, rendendola sicura da riprovare. Un codice di errore diverso DEVE essere utilizzato per le richieste che sono state elaborate dal server in qualsiasi modo.

I client possono riprovare le richieste che sono state rifiutate utilizzando REFUSED_STREAM, anche se la richiesta non è idempotente. Tuttavia, se il client sceglie di riprovare tale richiesta, DEVE presumere 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 memorizzabile nella cache non è riprovabile. Le richieste spinte che sono non memorizzabili nella cache o non sicure non sono consentite, come descritto in Sezione 8.4.1.

8.8. Examples (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 header compressa, che non è mostrata sopra il livello di frame HTTP/2.

8.8.1. Simple Request (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. Simple Response (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. Complex Request (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. Response with Body (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. Informational Responses (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!

References

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