Messaggi HTTP

I messaggi HTTP sono il modo in cui i dati vengono scambiati tra un server e un client. Esistono due tipi di messaggi: richieste inviate dal client per attivare un’azione sul server e risposte, la risposta dal server.

Gli sviluppatori Web, o webmaster, raramente creano da soli questi messaggi HTTP testuali: software, un browser Web, un proxy o un server Web eseguono questa azione. Forniscono messaggi HTTP tramite file di configurazione (per proxy o server), API (per browser) o altre interfacce.

Le richieste HTTP e le risposte condividono una struttura simile e sono composte da:

  1. Una riga di inizio che descrive le richieste da implementare o il suo stato, se riuscito o fallito. Questa è sempre una singola riga.
  2. Un set facoltativo di intestazioni HTTP che specificano la richiesta o descrivono il corpo incluso nel messaggio.
  3. Una riga vuota che indica che sono state inviate tutte le meta-informazioni per la richiesta.
  4. Un corpo facoltativo contenente dati associati alla richiesta (come il contenuto di un modulo HTML) o il documento associato a una risposta. La presenza del corpo e la sua dimensione sono specificate dalla riga di avvio e dalle intestazioni HTTP.

Le intestazioni della riga di avvio e HTTP del messaggio HTTP sono note collettivamente come head delle richieste e la parte successiva che ne contiene il contenuto è nota come body.

Richieste HTTP

Riga di richiesta

Nota: la riga di avvio è chiamata “riga di richiesta” nelle richieste.

Le richieste HTTP sono messaggi inviati dal client per avviare un’azione sul server. La loro riga di richiesta contiene tre elementi:

  1. Un metodo HTTP, un verbo (come GET, PUT o POST) o un sostantivo (come HEAD o OPTIONS), che descrive l’azione da eseguire. Ad esempio, GET indica che una risorsa deve essere recuperata o POST significa che i dati vengono inviati al server (creando o modificando una risorsa o generando un documento temporaneo da inviare).
  2. Il target della richiesta, solitamente un URL, o il percorso assoluto del protocollo, della porta e del dominio sono solitamente caratterizzati dal contesto della richiesta. Il formato di questo target della richiesta varia tra i diversi metodi HTTP. Può essere:
    • Un percorso assoluto, seguito in ultima analisi da un ‘?’ e una stringa di query. Questa è la forma più comune, nota come forma di origine, ed è utilizzata con i metodi GET, POST, HEAD e OPTIONS.
    • POST / HTTP/1.1
    • GET /sfondo.png HTTP/1.0
    • HEAD /test.html?query=google HTTP/1.1
    • OPTIONS /qualsiasi-pagina.html HTTP/1.0
  3. Un URL completo, noto come forma assoluta, è utilizzato principalmente con GET quando ci si connette a un proxy. GET https://wp-hosting.it/it/documenti/Web/HTTP/MessaggiHTTP/1.1
  4. Il componente di autorità di un URL, costituito dal nome di dominio e facoltativamente dalla porta (preceduta da un ‘:’), è chiamato forma di autorità. È utilizzato solo con CONNECT quando si imposta un tunnel HTTP. CONNECT wp-hosting.it:80 HTTP/1.1
  5. La forma asterisco, un semplice asterisco (‘*’) è utilizzato con OPTIONS, che rappresenta il server nel suo complesso. OPTIONS * HTTP/1.1
  6. La versione HTTP, che definisce la struttura del messaggio rimanente, fungendo da indicatore della versione prevista da utilizzare per la risposta.

Headers

Le Header HTTP di una richiesta seguono la stessa struttura di base di un’intestazione HTTP: una stringa non sensibile alle maiuscole/minuscole seguita da due punti (‘:’) e un valore la cui struttura dipende dall’intestazione. L’intera intestazione, incluso il valore, è composta da una singola riga, che può essere piuttosto lunga.

Nelle richieste possono apparire molte intestazioni diverse. Possono essere divise in diversi gruppi:

  • General headers, come Via, si applicano al messaggio nel suo complesso.
  • Request headers, come User-Agent o Accept, modificano la richiesta specificandola ulteriormente (come Accept-Language), fornendo contesto (come Referer) o limitandola in modo condizionale (come If-None-Match).
  • Representation headers come Content-Type che descrivono il formato originale dei dati del messaggio e qualsiasi codifica applicata (presente solo se il messaggio ha un corpo).

Body

L’ultima parte di una richiesta è il corpo. Non tutte le richieste ne hanno uno: le richieste con un metodo HTTP GET dovrebbero essere utilizzate solo per richiedere dati e non dovrebbero contenere un body.

I Bodies possono essere suddivisi in due categorie:

  • Body a risorsa singola, costituiti da un singolo file, definito dalle due intestazioni: Content-Type e Content-Length.
  • Body a risorse multiple, costituiti da un corpo multiparte, ognuno contenente un diverso bit di informazioni. Questo è in genere associato ai moduli HTML.

Risposte HTTP

Riga di stato

Nota: la riga di partenza è chiamata “riga di stato” nelle risposte.

La riga di partenza di una risposta HTTP, chiamata riga di stato, contiene le seguenti informazioni:

  1. La versione del protocollo, solitamente HTTP/1.1, ma può anche essere HTTP/1.0.
  2. Un codice di stato, che indica il successo o il fallimento della richiesta. I codici di stato comuni sono 200, 404 o 302.
  3. Un testo di stato. Una breve descrizione testuale puramente informativa del codice di stato per aiutare un essere umano a comprendere il messaggio HTTP.

Una tipica riga di stato appare così: HTTP/1.1 404 Not Found.

Headers

Le Header HTTP per le risposte seguono la stessa struttura di qualsiasi altra intestazione: una stringa non sensibile alle maiuscole/minuscole seguita da due punti (‘:’) e un valore la cui struttura dipende dal tipo di intestazione. L’intera intestazione, incluso il suo valore, si presenta come una singola riga.

Nelle risposte possono apparire molte intestazioni diverse. Queste possono essere divise in diversi gruppi:

Le General headers, come Via, si applicano all’intero messaggio.
Le Response headers, come Vary e Accept-Ranges, forniscono informazioni aggiuntive sul server che non rientrano nella riga di stato.
Le Representation header come Content-Type descrivono il formato originale dei dati del messaggio e qualsiasi codifica applicata (presenti solo se il messaggio ha un corpo).

esempio header risposte http

 

Body

L’ultima parte di una risposta è il Body. Non tutte le risposte ne hanno uno: le risposte con un codice di stato che risponde in modo sufficiente alla richiesta senza la necessità di includere contenuto (come 201 Creato o 204 Nessun contenuto) di solito non ne hanno uno.

I corpi possono essere suddivisi in tre categorie:

  • Body a risorsa singola, costituiti da un singolo file di lunghezza nota, definito dalle due intestazioni: Content-Type e Content-Length.
  • Body a risorsa singola, costituiti da un singolo file di lunghezza sconosciuta, codificato in blocchi con Transfer-Encoding impostato su chunked.
  • Body a risorse multiple, costituiti da un corpo multiparte, ognuno contenente una sezione diversa di informazioni. Questi sono relativamente rari.

Frame HTTP/2

I messaggi HTTP/1.x presentano alcuni svantaggi per le prestazioni:

  • Le Header, a differenza dei corpi, non sono compresse.
  • Le Header sono spesso molto simili da un messaggio all’altro, ma vengono comunque ripetute tra le connessioni.
  • Sebbene HTTP/1.1 abbia il pipelining, non è attivato di default nella maggior parte dei browser e non consente il multiplexing (ovvero l’invio di richieste contemporaneamente). Per inviare richieste contemporaneamente, è necessario aprire diverse connessioni sullo stesso server; e le connessioni TCP calde sono più efficienti di quelle fredde.

HTTP/2 introduce un passaggio extra: divide i messaggi HTTP/1.x in frame che sono incorporati in un flusso. I frame di dati e di intestazione sono separati, il che consente la compressione dell’intestazione. È possibile combinare diversi flussi insieme, un processo chiamato multiplexing, che consente un uso più efficiente delle connessioni TCP sottostanti.

framing binario

 

I frame HTTP sono ora trasparenti per gli sviluppatori Web. Questo è un passaggio aggiuntivo in HTTP/2, tra i messaggi HTTP/1.1 e il protocollo di trasporto sottostante. Non sono necessarie modifiche nelle API utilizzate dagli sviluppatori Web per utilizzare i frame HTTP; quando disponibile sia nel browser che nel server, HTTP/2 viene attivato e utilizzato.

Conclusione

I messaggi HTTP sono la chiave nell’utilizzo di HTTP; la loro struttura è semplice e sono altamente estensibili. Il meccanismo di framing HTTP/2 aggiunge un nuovo livello intermedio tra la sintassi HTTP/1.x e il protocollo di trasporto sottostante, senza modificarlo fondamentalmente: basandosi su meccanismi collaudati.