Hypertext Transfer Protocol: differenze tra le versioni

Versione delle 10:41, 24 giu 2022

Versione attuale delle 22:30, 26 mag 2025

(46 versioni intermedie di 27 utenti non mostrate)

Riga 1:

{{Nota disambigua||HTTP (disambigua)|HTTP}}

[[File:HTTP logo.svg|thumb|Logo dell'HTTP]]

In [[telecomunicazioni]] e [[informatica]] l''''HyperText Transfer Protocol''' ('''HTTP''') (in [[Lingua italiana|italiano]]: ''[[Protocollo (informatica)|protocollo]] di trasferimento di un [[ipertesto]]'') è un [[Protocollo di rete|protocollo]] a [[livello applicativo]] usato come principale sistema per la [[trasmissione (telecomunicazioni)|trasmissione]] d'[[informazione|informazioni]] sul [[web]] ovvero in un'[[architettura di rete|architettura]] tipica [[client-server]]. Le specifiche del protocollo sono gestite dal [[World Wide Web Consortium]] ([[World Wide Web Consortium|W3C]]). Un [[server]] HTTP generalmente resta in ascolto delle richieste dei [[client]] sulla [[Porta (reti)|porta]] 80 usando il protocollo [[Transmission Control Protocol|TCP]] a [[livello di trasporto]].

In [[telecomunicazioni]] e [[informatica]] l{{'}}'''HyperText Transfer Protocol''' ('''HTTP''') (in [[Lingua italiana{{lett|italiano]]:protocollo ''[[Protocolloper (informatica)|protocollo]] diil trasferimento di un [[ipertesto]]''}}) è un [[Protocollolivello di reteapplicazione|protocollo]] a [[livello applicativo]] usato come principale sistema per la [[trasmissione (telecomunicazioni)|trasmissione]] d'[[informazione|informazioni]] sulsu [[web]] ovvero in un'[[architettura di rete|architettura]] tipica [[client-serverinternet]]. Le specifiche del protocollo sono gestite dal [[World Wide Web Consortium]] ([[World Wide Web Consortium|W3C]]). Un [[server]] web|server HTTP]] generalmente resta in ascolto delle richieste dei [[client]] sulla [[Porta (reti)|porta]] 80 usando il protocollo [[Transmission Control Protocol|TCP]] a [[livello di trasporto]]80.

== Storia ==

La prima versione dell'HTTP, la 0.9, risale alla fine degli [[anni 1980]] e costituiva, insieme con il linguaggio [[HTML]] e gli [[Uniform Resource Locator|URL]], il nucleo base del ''[[World Wide Web]] (WWW) ''global information initiative'' sviluppata da [[Tim Berners-Lee]] al [[CERN]] di [[Ginevra]] per la condivisione delle informazioni tra la comunità dei [[fisica delle particelle|fisici delle alte energie]]. Prima di HTTP il protocollo di riferimento per tali scopi era il più semplice e leggero [[File Transfer Protocol|FTP]]. La prima versione effettivamente disponibile del protocollo, la HTTP/1.0, venne implementata dallo stesso Berners-Lee nel [[1991]] e proposta come RFC 1945<ref>{{IETF|1945}}</ref> all'ente normatore [[Internet Engineering Task Force|IETF]] nel 1996.

Con la diffusione di [[Mosaic|NCSA Mosaic]], un [[browser]] grafico di facile uso, il WWW conobbe un successo crescente e divennero evidenti alcuni limiti della versione 1.0 del protocollo, in particolare:

* l'impossibilità di ospitare più siti web sullo stesso [[server]] ([[virtual host|''virtual'' host]]);

* il mancato riuso delle connessioni disponibili;

* l'insufficienza dei meccanismi di [[sicurezza informatica|sicurezza]].

Il protocollo venne quindi esteso nella versione HTTP/1.1, presentato come RFC 2068<ref>{{IETF|2068}}</ref> nel [[1997]] e successivamente aggiornato nel [[1999]] come descritto dal RFC 2616<ref>{{IETF|2616}}</ref>.

=== Riepilogo delle versioni del protocollo HTTP ===

La nuova versione del protocollo, [[HTTP/2]], è stata pubblicata nella RFC 7540<ref>{{IETF|7540}}</ref> nel maggio 2015.

;HTTP/1.0

:La prima versione effettivamente disponibile del protocollo, la HTTP/1.0, venne implementata dallo stesso Berners-Lee nel 1991 e proposta come RFC 1945<ref>{{IETF|1945}}</ref> all'ente normatore [[Internet Engineering Task Force|IETF]] nel 1996.

;HTTP/1.1

:Il protocollo venne quindi esteso nella versione HTTP/1.1, presentato come RFC 2068<ref>{{IETF|2068}}</ref> nel [[1997]] e successivamente aggiornato nel [[1999]] come descritto dal RFC 2616<ref>{{IETF|2616}}</ref>.

;HTTP/2

:La nuova versione del protocollo, [[HTTP/2]], è stata pubblicata nella RFC 7540<ref>{{IETF|7540}}</ref> nel maggio 2015.

;HTTP/3

:La terza versione del protocollo, [[HTTP/3]], è stata pubblicata nella RFC 9114<ref>{{IETF|9114}}</ref> il 6 giugno 2022.

== Funzionamento ==

L'<small>HTTP</small> è un protocollo che lavora con un'architettura di tipo [[client/server]]: il [[client]] esegue una richiesta e il [[server]] restituisce la risposta mandata da un altro host. Nell'uso comune il client corrisponde al [[browser]] ede il server la macchina su cui risiede il [[sito web]]. Vi sono quindi due tipi di messaggi <small>HTTP</small>: messaggi richiesta (detti ''HTTP requests'') e messaggi risposta (detti ''HTTP responses'').

<small>HTTP</small> differisce da altri protocolli di [[livello applicazioni|livello 7]] come [[File Transfer Protocol|FTP]], per il fatto che le [[connessione (informatica)|connessioni]] vengono generalmente chiuse una volta che una particolare richiesta (o una serie di richieste correlate) è stata soddisfatta. Questo comportamento rende il protocollo <small>HTTP</small> ideale per il World Wide Web, in cui le pagine molto spesso contengono dei [[Collegamento ipertestuale|collegamenti]] (''link'') a pagine ospitate da altri server diminuendo così il numero di connessioni attive limitandole a quelle effettivamente necessarie con aumento quindi di efficienza (minor carico e occupazione) sia sul client che sul server. Talvolta però pone problemi agli sviluppatori di contenuti web, perché la natura senza stato (''stateless'') della [[sessione]] di navigazione costringe ada utilizzare dei metodi alternativi -— tipicamente basati sui [[cookie]] -— per conservare lo stato dell'utente.

=== Messaggio di richiesta ===

Il messaggio di richiesta è composto da quattro parti:

* riga di richiesta (''request line'');

* sezione ''header'' (informazioni aggiuntive);

* riga vuota (CRLF: i 2due caratteri ''[[carriage return]]'' e ''line feed'');

* ''body'' (corpo del messaggio).

==== Riga di richiesta ====

La riga di richiesta è composta da metodo, [[Uniform Resource Identifier|<small>URI</small>]] e versione del protocollo.

Il metodo di richiesta, per la versione 1.1, può essere uno dei seguenti:

* <kbdcode>GET</kbdcode>

* <kbdcode>POST</kbdcode>

* <kbdcode>HEAD</kbdcode>

* <kbdcode>PUT</kbdcode>

* <kbdcode>DELETE</kbdcode>

* <kbdcode>PATCH</kbdcode>

* <kbdcode>TRACE</kbdcode>

* <kbdcode>OPTIONS</kbdcode>

* <kbdcode>CONNECT</kbdcode>

l'<small>URI</small>, ''uniform resource identifier'' (identificatore univoco di risorsa), indica l'oggetto della richiesta (ad esempio la [[pagina web]] che si intende ottenere).

I metodi <small>HTTP</small> più comuni sono <smallcode>GET</smallcode>, <smallcode>HEAD</smallcode> e <smallcode>POST</smallcode>.

Il metodo <smallcode>GET</smallcode> è usato per ottenere il contenuto della risorsa indicata come <small>URI</small> (come può essere il contenuto di una pagina <small>HTML</small>). <smallcode>HEAD</smallcode> è analogo a <smallcode>GET</smallcode>, ma restituisce solo i campi dell'header, ad esempio per verificare la data di modifica del file.

Una richiesta con metodo <smallcode>HEAD</smallcode> non prevede l'uso del ''body''.

Il metodo <smallcode>POST</smallcode> è usato di norma per inviare informazioni al server (ad esempio i dati di un [[form]]).

In questo caso l'<small>URI</small> indica che cosa si sta inviando e il ''body'' ne indica il contenuto.

==== Gli header della richiesta ====

Gli header di richiesta più comuni sono:

:'''<code>Host'''</code>: nome del server a cui si riferisce l'<small>URL</small>. È obbligatorio nelle richieste conformi HTTP/1.1 perché permette l'uso dei ''virtual host'' basati sui nomi.

:'''<code>User-Agent'''</code>: identificazione del tipo di client: tipo browser, produttore, versione ecc...

:'''<code>Cookie</code>:''' utilizzati dalle applicazioni web per archiviare e recuperare informazioni a lungo termine sul lato client. Spesso usati per memorizzare un token di autenticazione o per tracciare le attività dell'utente.

=== Messaggio di risposta ===

Il messaggio di risposta è di tipo testuale ed è composto da quattro parti:

* riga di stato (''status-line'');

* sezione ''header'';

* riga vuota (CRLF: i 2 caratteri carriage return e line feed);

* ''body'' (contenuto della risposta).

==== Riga di stato ====

{{vedi anche|Codici di stato HTTP}}

La riga di stato riporta un codice a tre cifre catalogato nel seguente modo:

* <code>1xx</code>: Informational (messaggi informativi)

* <code>2xx</code>: Successful (la richiesta è stata soddisfatta)

* 1xx: Informational (messaggi informativi)

* <code>3xx</code>: Redirection (non c'è risposta immediata, ma la richiesta è sensata e viene detto come ottenere la risposta)

* 2xx: Successful (la richiesta è stata soddisfatta)

* 5xx<code>4xx</code>: ServerClient error (la richiesta non può essere soddisfatta perperché un problema interno del serversbagliata)

* 3xx: Redirection (non c'è risposta immediata, ma la richiesta è sensata e viene detto come ottenere la risposta)

* 4xx<code>5xx</code>: ClientServer error (la richiesta non può essere soddisfatta perchéper sbagliataun problema interno del server)

* 5xx: Server error (la richiesta non può essere soddisfatta per un problema interno del server)

I codici di risposta più comuni sono:

* '''<code>200 <small>OK</smallcode>'''. Il server ha fornito correttamente il contenuto nella sezione ''body''.

* '''<code>301 Moved Permanently'''</code>. La risorsa che abbiamo richiesto non è raggiungibile perché è stata spostata in modo permanente.

* '''200 <small>OK</small>'''. Il server ha fornito correttamente il contenuto nella sezione body.

* '''<code>302 Found'''</code>. La risorsa è raggiungibile con un altro URI indicato nel header Location. Di norma i browser eseguono la richiesta all'URI indicato in modo automatico senza interazione dell'utente.

* '''301 Moved Permanently'''. La risorsa che abbiamo richiesto non è raggiungibile perché è stata spostata in modo permanente.

* '''<code>400 Bad Request'''</code>. La risorsa richiesta non è comprensibile al server.

* '''302 Found'''. La risorsa è raggiungibile con un altro URI indicato nel header Location. Di norma i browser eseguono la richiesta all'URI indicato in modo automatico senza interazione dell'utente.

* '''<code>[[Errore 404|404 Not Found]]'''</code>. La risorsa richiesta non è stata trovata e non se ne conosce l'ubicazione. Di solito avviene quando l'URI è stato indicato in modo incorretto, oppure è stato rimosso il contenuto dal server.

* '''400 Bad Request'''. La risorsa richiesta non è comprensibile al server.

* '''<code>500 Internal Server Error'''</code>. Il server non è in grado di rispondere alla richiesta per un suo problema interno.

* '''[[Errore 404|404 Not Found]]'''. La risorsa richiesta non è stata trovata e non se ne conosce l'ubicazione. Di solito avviene quando l'URI è stato indicato in modo incorretto, oppure è stato rimosso il contenuto dal server.

* '''<code>502 Bad Gateway.'''</code> Il server web che agisce come ''[[reverse proxy]]'' non ha ottenuto una risposta valida dal server di ''[[Upstream (informatica)|upstream]]''.

* '''500 Internal Server Error'''. Il server non è in grado di rispondere alla richiesta per un suo problema interno.

* '''<code>505 HTTP Version Not Supported'''</code>. La versione di http non è supportata.

* '''502 Bad Gateway.''' Il server web che agisce come [[reverse proxy]] non ha ottenuto una risposta valida dal server di upstream.

* '''505 HTTP Version Not Supported'''. La versione di http non è supportata.

==== Gli header della risposta ====

Gli header della risposta più comuni sono:

* '''<code>Server'''</code>. Indica il tipo e la versione del server. Può essere visto come l'equivalente dell'header di richiesta <code>User-Agent</code>

* '''<code>Content-Type'''</code>. Indica il tipo di contenuto restituito. La codifica di tali tipi (detti [[Media type]]) è registrata presso lo '''[[IANA]]''' ('''I'''nternetInternet '''A'''ssignedAssigned '''N'''umberNumber '''A'''uthorityAuthority); essi sono detti tipi '''[[MIME]]''' ('''M'''ultimediaMultimedia '''I'''nternetInternet '''M'''ailMail '''E'''xtensionsExtensions), la cui codifica è descritta nel documento RFC 1521. Alcuni usuali tipi MIME incontrati in una risposta HTTP sono:

** '''<code>text/html'''</code> Documento HTML

** '''<code>text/plain'''</code> Documento di testo non formattato

** '''<code>text/xml'''</code> Documento '''[[XML]]'''

** '''<code>image/jpeg'''</code> Immagine di formato '''[[Joint Photographic Experts Group|JPEG]]'''

=== Tipo di connessione ===

Il client può chiedere al server, nel messaggio di richiesta, di utilizzare due tipi di comunicazione.:

* Non persistente: Per ogni richiesta e relativa risposta, viene stabilita una connessione TCP dedicata.

Il client può chiedere al server, nel messaggio di richiesta, di utilizzare due tipi di comunicazione.

* Persistente: Ogni richiesta e relativa risposta è trasferita utilizzando la stessa connessione TCP. È il comportamento predefinito di HTTP 1.1.

;Non persistente

Da un lato, le connessioni non persistenti introducono una latenza aggiuntiva rispetto a quelle persistenti di almeno 3tre [[Round Trip Time]] (RTT).

:Per ogni richiesta e relativa risposta, viene stabilita una connessione TCP dedicata.

Infatti, al termine di ogni risposta da parte del server si rendono necessari:

;Persistente

* 1.,5 o 2 RTT per la chiusura della connessione corrente, con la sua stretta di mano conclusiva a tre o quattro passaggi di FIN ede ACK (''three-'' o ''four-way handshake'').

:Ogni richiesta e relativa risposta è trasferita utilizzando la stessa connessione TCP. È il comportamento predefinito di HTTP 1.1.

* 1.,5 RTT per l'apertura della nuova connessione, per i tre passaggi di SYN e ACK.

Da un lato, le connessioni non persistenti introducono una latenza aggiuntiva rispetto a quelle persistenti di almeno 3 [[Round Trip Time]] (RTT).

D'altro canto, le connessioni persistenti precludono il parallelismo nelle comunicazioni, giacché il client che abbia diverse richieste da inviare allo stesso server è costretto ada evaderle sequenzialmente, una dopo l'altra.

Infatti, al termine di ogni risposta da parte del server si rendono necessari

* 1.5 o 2 RTT per la chiusura della connessione corrente, con la sua stretta di mano conclusiva a tre o quattro passaggi di FIN ed ACK (''three-'' o ''four-way handshake'').

* 1.5 RTT per l'apertura della nuova connessione, per i tre passaggi di SYN e ACK.

D'altro canto, le connessioni persistenti precludono il parallelismo nelle comunicazioni, giacché il client che abbia diverse richieste da inviare allo stesso server è costretto ad evaderle sequenzialmente, una dopo l'altra.

Per queste ragioni, i browser solitamente sfruttano le complementarità prestazionali delle due politiche di comunicazione per massimizzare la loro efficienza: solitamente aprono con ogni server diverse connessioni TCP in parallelo, su cui comunicano con strategia persistente.

Riga 107 ⟶ 115:

Seguono esempi di messaggi di richiesta e risposta HTTP/1.1.

Gli esempi riguardano il recupero di contenuti su questa enciclopedia web e possono essere riprodotti -— e quindi verificati -— sul proprio PC copiando e incollando il testo con un client TCP (adper esesempio: <code>telnet it.wikipedia.org 80</code> nel caso di URL http://), oppure client TCP con supporto SSL (ad esesempio: <code>openssl s_client -connect it.wikipedia.org:443</code> nel caso di URL https://).

Ai fini della riproduzione si annota che:

* l'unico header obbligatorio nella richiesta HTTP/1.1 è l{{'}}''header'' <code>Host</code> contenente la parte host dell'URL (come scritto sopra);

* in genere i browser aggiungono l{{'}}''header'' <code>Accept-Encoding</code> per specificare la possibilità di ricevere la risposta in formato compresso. L'header è eliminato per rendere leggibile la risposta (es: <code>Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity</code>);

* al termine degli header è obbligatoria sempre una riga vuota (ossia due "a capo" consecutivi)

* le parti identificate con [...] indicano le parti omesse

Riga 118 ⟶ 126:

Recupera la risorsa web presente all'URL https://it.wikipedia.org/wiki/Pagina_principale

<syntaxhighlight lang="http" line="1">

GET /wiki/Pagina_principale HTTP/1.1

Host: it.wikipedia.org

Riga 160 ⟶ 168:

La richiesta rimane la stessa dell'esempio precedente.

La risposta cambia esponendo un codice di spostamento permanente (<code>301 Moved Permanently</code>):

<syntaxhighlight lang="http" line="1">

HTTP/1.1 301 Moved Permanently

Date: Wed, 19 Apr 2017 16:50:43 GMT

Riga 171 ⟶ 179:

=== Richiesta POST e risposta di redirezione temporanea ===

Questa è una richiesta <code>POST</code> per modificare le proprie preferenze di Wikipedianowikipediano con il tema "Cologne Blue" (la sottostringa <kbdcode>&wpskin=cologneblue</kbdcode> nella prima riga del corpo della richiesta <code>POST</code>)

<syntaxhighlight lang="http" line="1">

POST /wiki/Speciale:Preferenze HTTP/1.1

Host: it.wikipedia.org

Riga 190 ⟶ 198:

Risposta HTTP di redirezione temporanea (302 Found) rimanda alla pagina per il login

<syntaxhighlight lang="http" line="1">

HTTP/1.1 302 Found

Date: Wed, 19 Apr 2017 17:21:16 GMT

Riga 205 ⟶ 213:

=== Richieste utili nella versione 1.0 ===

==== GET / HTTP/1.0 ====

La GET nella versione HTTP/1.0 risulta comoda per le docenze, si può effettuare con una sola riga perché nella versione 1.0 del protocollo non era obbligatorio inserire l'header "Host:"

Riga 218 ⟶ 225:

==== HEAD / HTTP/1.0 ====

Risulta allo stesso modo molto comodo effettuare la richiesta <code>HEAD</code> del protocollo che restituisce le sole intestazioni con:

Risulta allo stesso modo molto comodo effettuare la richiesta HEAD del protocollo che restituisce le sole intestazioni con:

<syntaxhighlight lang="http">

Riga 225 ⟶ 231:

</syntaxhighlight>

== Versioni ''sicure'' ==

Dal momento che tutto il traffico HTTP è anonimo e ''in chiaro'', sono state sviluppate diverse alternative per garantire differenti livelli di [[Sicurezza informatica|sicurezza]], in termini di:

* [[cifratura]] del [[traffico (telecomunicazioni)|traffico]];

* verifica di [[integrità dei dati|integrità del traffico]];

Riga 235 ⟶ 240:

La prima proposta venne direttamente da [[NCSA Mosaic|NCSA]], con le versioni server 1.1 e client 2.2 che supportavano un meccanismo di autenticazione utente e cifratura dati basati su messaggi formato [[Privacy-Enhanced Electronic Mail|PEM]] e chiavi [[Pretty Good Privacy|PGP]].

In seguito, sono state standardizzate due versioni ''sicure'' del protocollo HTTP chiamate '''[[SHTTP]]''' e '''[[HTTPS]]'''. La prima, modellata sulla posta cifrata [[S/MIME]], è ormai caduta in disuso e prevede meccanismi crittografici a livello di ''[[Carico utile (informatica)|payload]]'': le richieste e gli header vengono scambiati in chiaro mentre il contenuto della ''pagina'' viene cifrato come una struttura [[MIME]] ''multipart''. Il meccanismo HTTPS, inventato da [[Netscape]], usa invece il sottostante canale [[Crittografia|cifrato]] a livello di [[Rete informatica|trasporto]] mediante [[Transport Layer Security|SSL]] o [[Transport Layer Security|TLS]] per impedire l'intercettazione di qualsiasi parte della transazione. Entrambi i protocolli possono garantire l'identità del mittente, ma solo SHTTP è in grado di garantire anche l'integrità del contenuto dopo averlo, ad esempio, memorizzato su un disco.

== Streaming HTTP ==

La fruizione nelle pagine WEB di materiale [[multimedialità|multimediale]], quale [[audio]] o [[video]] viene gestito in modo del tutto analogo al [[download]] dei file, tramite un '''caricamento progressivo''' o '''distribuzione progressiva''', in cui il file viene scaricato in modo progressivo dall'inizio alla fine (tramite i protocolli ''[[Real Time Streaming Protocol]]'' e ''[[Real-time Transport Protocol]]'') e nel caso il [[bit-rate]] sia eccessivo per la rete che lo trasporta può verificarsi un continuo ricaricamento del [[buffer]]

Per evitare questi inconvenienti esistono altri sistemi alternativi, che permettono l'adattamento del file alla rete dell'utente finale, questi sistemi sono caratterizzati dai protocolli:

Riga 254 ⟶ 259:

* RFC 1945 (Specifiche HTTP 1.0)

* RFC 2616 (Specifiche HTTP 1.1)

* RFC 7540 (Specifiche HTTP 2.0)

* RFC 9114 (Specifiche HTTP 3.0)

== Voci correlate ==

* [[Do not track header]]

* [[File Transfer Protocol]] (FTP)

* [[HTTP tunneling]]

* [[Protocollo di rete]]

Riga 264 ⟶ 271:

== Altri progetti ==

{{interprogetto|preposizione=sull'|wikt=HTTP|wikt_etichetta=HTTP}}

== Collegamenti esterni ==

* {{Collegamenti esterni}}

* {{FOLDOC|Hypertext Transfer Protocol}}

{{Browser Internet}}

{{IPstack}}

{{Web semantico}}

{{Interfacce web}}

{{Controllo di autorità}}

{{Portale|internet|telematica}}