Hypertext Transfer Protocol: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
Mfprimo (discussione | contributi)
m Linea di richiesta: Correzione metodi
Nessun oggetto della modifica
 
(395 versioni intermedie di oltre 100 utenti non mostrate)
Riga 1:
{{Nota disambigua||HTTP (disambigua)|HTTP}}
{{IPstack}}
[[File:HTTP logo.svg|thumb|Logo dell'HTTP]]
 
'''HTTP'''In è[[telecomunicazioni]] l'acronimoe di[[informatica]] l{{'}}''H'''yper'''T'''extHyperText Transfer Protocol'''T'''ransfer ('''PHTTP'''rotocol) ({{lett|protocollo diper il trasferimento di un [[ipertesto]]}}). Usatoè un [[livello di applicazione|protocollo applicativo]] usato come principale sistema per la [[trasmissione di(telecomunicazioni)|trasmissione]] d'[[informazione|informazioni]] sulsu [[webinternet]]. Le specifiche del protocollo sono attualmentegestite in carica aldal [[W3CWorld 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]] [[Transmission Control Protocol|TCP]] 80.
 
== Storia ==
La prima versione, la 0.9, dell'HTTP risale alla fine degli anni '80 del [[XX secolo]] e costituiva, insieme con l'[[HTML]] e gli [[Uniform Resource Locator|URL]], il nucleo base della "World-Wide Web [[WWW]] global information initiative" portata avanti da [[Tim Berners-Lee]] al [[CERN]] di [[Ginevra (città)|Ginevra]] per la condivisione delle informazioni tra la comunità dei [[Fisica|fisici]] delle [[Energia|alte energie]].
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 all'ente normatore [[IETF]] nel 1996.
Con la diffusione di [[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 www sullo stesso server ([[virtual host]])
*il mancato riuso delle connessioni disponibili
*l'insufficienza dei meccanismi di sicurezza
Il protocollo venne quindi esteso nella versione HTTP/1.1, presentato come RFC 2068 nel 1997.
 
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'HTTP funziona su un meccanismo richiesta/risposta: il client esegue una richiesta ed il server restituisce la risposta. Nell'uso comune il client corrisponde al browser ed il server al sito web.
* l'impossibilità di ospitare più siti web sullo stesso [[server]] ([[virtual host|''virtual'' host]]);
Vi sono quindi due tipi di messaggi HTTP: messaggi richiesta e messaggi risposta.
* il mancato riuso delle connessioni disponibili;
* l'insufficienza dei meccanismi di [[sicurezza informatica|sicurezza]].
 
=== Riepilogo delle versioni del protocollo HTTP ===
HTTP differisce da altri protocolli di [[livello applicazioni|livello 5]] come FTP, per il fatto che le connessioni vengono generalmente chiuse una volta che una particolare richiesta (o una serie di richieste correlate) è stata soddisfatta. Questo comportamento rende il protocollo HTTP ideale per il World Wide Web, in cui le pagine molto spesso contengono dei collegamenti (''link'') a pagine ospitate da altri server. Talvolta però pone problemi agli sviluppatori di contenuti web, perché la natura senza stato (''stateless'') costringe ad utilizzare dei metodi alternativi per conservare lo stato dell'utente. Spesso questi metodi si basano sull'uso dei [[cookie]] .
;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
== Messaggio di richiesta ==
: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>.
Il messaggio richiesta è composto di tre parti:
* Linea di richiesta (request line)
* Sezione Header (informazioni aggiuntive)
* Body (corpo del messaggio)
 
;HTTP/2
=== Linea di richiesta ===
:La nuova versione del protocollo, [[HTTP/2]], è stata pubblicata nella RFC 7540<ref>{{IETF|7540}}</ref> nel maggio 2015.
La linea di richiesta è composta dal metodo, URI e versione del protocollo.
Il metodo di richiesta, per la versione 1.1, può essere uno dei seguenti:
* GET
* POST
* HEAD
* PUT
* DELETE
* TRACE
* OPTIONS
 
;HTTP/3
l<nowiki>'</nowiki>'''[[URI]]''' sta per '''U'''niform '''R'''esource '''I'''dentifier ed indica l'oggetto della richiesta (ad esempio la pagina web che si intende ottenere)
:La terza versione del protocollo, [[HTTP/3]], è stata pubblicata nella RFC 9114<ref>{{IETF|9114}}</ref> il 6 giugno 2022.
 
== Funzionamento ==
I metodi HTTP più comuni sono GET, HEAD e POST.
L'HTTP è 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]] e il server la macchina su cui risiede il [[sito web]]. Vi sono quindi due tipi di messaggi HTTP: messaggi richiesta (detti ''HTTP requests'') e messaggi risposta (detti ''HTTP responses'').
Il metodo GET è usato per ottenere il contenuto della risorsa indicata come URI (come può essere il contenuto di una pagina HTML). HEAD è anolog a GET, ma restituisce solo i campi dell'header, ad esempio per verificare la data di modifica del file.
Una richiesta con metodo GET non prevede l'uso del body
 
HTTP 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 HTTP 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 a utilizzare dei metodi alternativi — tipicamente basati sui [[cookie]] — per conservare lo stato dell'utente.
Il metodo POST è usato di norma per inviare informazioni al server (ad esempio i dati di un form).
In questo caso l'URI indica che cosa si sta inviando e il body ne indica il contenuto.
 
=== GliMessaggio header delladi richiesta ===
GliIl headermessaggio di richiesta piùè comunicomposto sonoda quattro parti:
* riga di richiesta (''request line'');
* sezione ''header'' (informazioni aggiuntive);
* riga vuota (CRLF: i due caratteri ''[[carriage return]]'' e ''line feed'');
* ''body'' (corpo del messaggio).
 
==== Riga di richiesta ====
'''Host''': Nome del server a cui si riferisce l'URI. È obbligatorio nelle richieste conformi HTTP/1.1 perché permette l'uso dei ''virtual host'' basati sui nomi.
La riga di richiesta è composta da metodo, [[Uniform Resource Identifier|URI]] e versione del protocollo.
Il metodo di richiesta, per la versione 1.1, può essere uno dei seguenti:
* <code>GET</code>
* <code>POST</code>
* <code>HEAD</code>
* <code>PUT</code>
* <code>DELETE</code>
* <code>PATCH</code>
* <code>TRACE</code>
* <code>OPTIONS</code>
* <code>CONNECT</code>
 
l'URI, ''uniform resource identifier'' (identificatore univoco di risorsa), indica l'oggetto della richiesta (ad esempio la [[pagina web]] che si intende ottenere).
'''User-Agent''': Identificazione del tipo di client: tipo browser, produttore, versione...
 
I metodi HTTP più comuni sono <code>GET</code>, <code>HEAD</code> e <code>POST</code>.
== Messaggio di risposta ==
Il metodo <code>GET</code> è usato per ottenere il contenuto della risorsa indicata come URI (come può essere il contenuto di una pagina HTML). <code>HEAD</code> è analogo a <code>GET</code>, ma restituisce solo i campi dell'header, ad esempio per verificare la data di modifica del file.
Il messaggio di risposta è composto dalle seguenti tre parti:
Una richiesta con metodo <code>HEAD</code> non prevede l'uso del ''body''.
* Linea di stato (status-line)
* Sezione header
* Body (contenuto della risposta)
 
Il metodo <code>POST</code> è usato di norma per inviare informazioni al server (ad esempio i dati di un [[form]]).
=== Linea di stato ===
In questo caso l'URI indica che cosa si sta inviando e il ''body'' ne indica il contenuto.
La linea di stato riporta un codice a tre cifre catalogato nel seguento modo:
 
==== Gli header della richiesta ====
* 1xx : Informational
Gli header di richiesta più comuni sono:
* 2xx: Success
:<code>Host</code>: nome del server a cui si riferisce l'URL. È obbligatorio nelle richieste conformi HTTP/1.1 perché permette l'uso dei ''virtual host'' basati sui nomi.
* 3xx: Redirection
:<code>User-Agent</code>: identificazione del tipo di client: tipo browser, produttore, versione ecc...
* 4xx: Client error
:<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.
* 5xx: Server error
 
=== Messaggio di risposta ===
Nel caso più comune il server risponde con un codice 200 (OK) e fornisce contentuto nella sezione body.
Il messaggio di risposta è di tipo testuale ed è composto da quattro parti:
Altri casi comuni sono:
* 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 ====
'''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.
{{vedi anche|Codici di stato HTTP}}
 
La riga di stato riporta un codice a tre cifre catalogato nel seguente modo:
'''404 Not Found'''. La risorsa richiesta non è stata trovata e non se ne conosce l'ubicazione. Di solito avviene quando l'URI indicato in modo incorretto od è stato rimosso il contenuto dal server.
* <code>1xx</code>: Informational (messaggi informativi)
* <code>2xx</code>: Successful (la richiesta è stata soddisfatta)
* <code>3xx</code>: Redirection (non c'è risposta immediata, ma la richiesta è sensata e viene detto come ottenere la risposta)
* <code>4xx</code>: Client error (la richiesta non può essere soddisfatta perché sbagliata)
* <code>5xx</code>: Server error (la richiesta non può essere soddisfatta per un problema interno del server)
 
I codici di risposta più comuni sono:
'''500 Internal Server Error'''. Il server non è in grado di rispondere alla richiesta per un suo problema interno.
* <code>200 OK</code>. 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.
* <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.
* <code>400 Bad Request</code>. La risorsa richiesta non è comprensibile al server.
* <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.
* <code>500 Internal Server Error</code>. Il server non è in grado di rispondere alla richiesta per un suo problema interno.
* <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]]''.
* <code>505 HTTP Version Not Supported</code>. La versione di http non è supportata.
 
==== Gli header della risposta ====
Gli header della risposta più comuni sono:
* '''<code>Server'''</code>. Indica il tipo la marca ,e la versione del server. UnPuò po'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]]) sonoè registratiregistrata presso '''lo [[IANA]]''' ('''I'''nternetInternet '''A'''ssignedAssigned '''N'''umber '''A'''uthorityNumber Authority); eessi sono detti tipi '''[[MIME]]''' ('''M'''ultimediaMultimedia '''I'''nternetInternet '''M'''essageMail '''E'''xtensionsExtensions), la lorocui codifica è descritta nel documento RFC 1521. IAlcuni usuali tipi MIME incontrati in una risposta principaliHTTP sono:
** '''<code>text/html'''.</code> Documento HTML)
** '''<code>text/plaintext'''.plain</code> Documento di testo non formattato)
** <code>text/xml</code> Documento [[XML]]
** '''image/jpeg'''.Immagine di fromato '''[[Joint Photographic Experts Group|JPEG]]'''
** <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.
* Persistente: Ogni richiesta e relativa risposta è trasferita utilizzando la stessa connessione TCP. È il comportamento predefinito di HTTP 1.1.
Da un lato, le connessioni non persistenti introducono una latenza aggiuntiva rispetto a quelle persistenti di almeno tre [[Round Trip Time]] (RTT).
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 e 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 a 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.
 
== Esempi di messaggi HTTP ==
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 (per esempio: <code>telnet it.wikipedia.org 80</code> nel caso di URL http://), oppure client TCP con supporto SSL (ad esempio: <code>openssl s_client -connect it.wikipedia.org:443</code> nel caso di URL https://).
Richiesta:
 
Ai fini della riproduzione si annota che:
GET /wiki/Pagina_principale HTTP/1.1
* l'unico header obbligatorio nella richiesta HTTP/1.1 è l{{'}}''header'' <code>Host</code> contenente la parte host dell'URL (come scritto sopra);
Connection: Keep-Alive
* 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>);
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
* al termine degli header è obbligatoria sempre una riga vuota (ossia due "a capo" consecutivi)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
* le parti identificate con [...] indicano le parti omesse
Accept-Encoding: x-gzip, x-deflate, gzip, deflate, identity
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: en
Host: it.wikipedia.org
 
=== Richiesta GET e risposta di successo ===
Risposta:
Recupera la risorsa web presente all'URL https://it.wikipedia.org/wiki/Pagina_principale
 
<syntaxhighlight lang="http" line="1">
HTTP/1.0 200 OK
GET /wiki/Pagina_principale HTTP/1.1
Date: Mon, 28 Jun 2004 10:47:31 GMT
Host: it.wikipedia.org
Server: Apache/1.3.29 (Unix) PHP/4.3.4
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
X-Powered-By: PHP/4.3.4
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Vary: Accept-Encoding,Cookie
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
ContentAccept-Language: it
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
</syntaxhighlight>
Age: 7673
X-Cache: HIT from wikipedia.org
Connection: close
<HTML>
[ ...]
 
Risposta di successo (200 OK):
==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
 
<syntaxhighlight lang="http">
*cifratura del traffico
HTTP/1.1 200 OK
*verifica di integrità del traffico
Date: Fri, 22 Feb 2019 10:50:37 GMT
*autenticazione del server
Content-Type: text/html; charset=UTF-8
*autenticazione dell'utente
Content-Length: 22208
Connection: keep-alive
Server: mw1215.eqiad.wmnet
Content-language: it
Content-Encoding: gzip
Last-Modified: Fri, 22 Feb 2019 08:46:20 GMT
Age: 20548
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
Vary: Accept-Encoding,Cookie,Authorization
[...]
<!DOCTYPE html>
<html class="client-nojs" lang="it" dir="ltr">
<head>
<meta charset="UTF-8"/>
<title>Wikipedia, l'enciclopedia libera</title>
[...]
</body>
</html>
</syntaxhighlight>
 
=== Richiesta GET e risposta di redirezione permanente ===
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]].
Qui il client recupera l'URL [[Pagina principale|http://it.wikipedia.org/wiki/Pagina_principale]] (differisce dal precedente poiché http invece di https).
 
La richiesta rimane la stessa dell'esempio precedente.
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 ''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|trasporto]] mediante [[SSL]] o [[Transport Layer Security|TLS]] per impedire l'intercettazione di qualsiasi parte della transazione. Entrambe i protocolli possono garantire l'[[Identità|identità]] del mittente, ma solo SHTTP è in grado di garantire anche l'[[Integrità|integrità]] del contenuto dopo averlo, ad esempio, memorizzato su un disco.
 
La risposta cambia esponendo un codice di spostamento permanente (<code>301 Moved Permanently</code>):
== Riferimenti ==
<syntaxhighlight lang="http" line="1">
HTTP/1.1 301 Moved Permanently
Date: Wed, 19 Apr 2017 16:50:43 GMT
Server: Varnish
Location: https://it.wikipedia.org/wiki/Pagina_principale
Content-Length: 0
Connection: keep-alive
</syntaxhighlight>
 
=== Richiesta POST e risposta di redirezione temporanea ===
Questa è una richiesta <code>POST</code> per modificare le proprie preferenze di wikipediano con il tema "Cologne Blue" (la sottostringa <code>&wpskin=cologneblue</code> 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
User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko)
Accept: text/html, image/jpeg, image/png, text/*, image/*, */*
Accept-Charset: iso-8859-1, utf-8;q=0.5, *;q=0.5
Accept-Language: it
Connection: Keep-Alive
Cache-control:no-cache
Content-length:1291
Content-type:application/x-www-form-urlencoded
wplanguage=it&wpgender=unknown&wpnickname=&wpdisablemail=1&wpskin=cologneblue&wppopups=0&wpdate=default&wpServerTime=1034&wptimecorrection=System%7C120&wptimecorrection-other=02%3A00&wpimagesize=2&wpthumbsize=2&wpmultimediaviewer-enable=1&wpunderline=2&wpstubthreshold=0&wpmath=mathml&wpcompact-language-links=1&wpeditfont=default&wpuseeditwarning=1&wpshowtoolbar=1&wpusebetatoolbar=1&wpusebetatoolbar-cgd=1&wppreviewontop=1&wprcdays=7&wprclimit=50&wphidecategorization=1&wpwatchlistdays=3&wpwllimit=250&wpwatchlisthidecategorization=1&wpcirrussearch-pref-completion-profile=fuzzy&wpgadgets%5B%5D=HiddenCat&wpgadgets%5B%5D=OpenStreetMap&wpgadgets%5B%5D=ReferenceTooltips&wpgadgets%5B%5D=WikiMiniAtlas&wpgadgets%5B%5D=ExternalSearch&wpecho-email-frequency=0&wpecho-email-format=html&wpecho-subscriptions%5B%5D=email-edit-user-talk&wpecho-subscriptions%5B%5D=web-edit-thank&wpecho-subscriptions%5B%5D=web-flow-discussion&wpecho-subscriptions%5B%5D=web-mention&wpecho-subscriptions%5B%5D=web-user-rights&wpecho-subscriptions%5B%5D=email-user-rights&wpecho-subscriptions%5B%5D=web-reverted&wpecho-subscriptions%5B%5D=web-emailuser&wpecho-cross-wiki-notifications=1&wpecho-show-alert=1&wpEditToken=dc1583a58b9a1293689802ce0700c46e58f79b12%2B%5C&title=Speciale%3APreferenze&wpenotifusertalkpages
</syntaxhighlight>
 
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
Content-Type: text/html; charset=utf-8
Content-Length: 0
Connection: keep-alive
Server: mw2224.codfw.wmnet
Vary: Accept-Encoding,X-Forwarded-Proto,Cookie,Authorization
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Location: https://it.wikipedia.org/w/index.php?title=Speciale:Entra&returnto=Speciale%3APreferenze&returntoquery=&warning=prefsnologintext2
Age: 0
Cache-Control: private, s-maxage=0, max-age=0, must-revalidate
</syntaxhighlight>
 
=== 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:"
 
Per eseguirla si fa:
 
<syntaxhighlight lang="http">
GET / HTTP/1.0
</syntaxhighlight>
 
Si ricorda di lasciare una riga vuota dopo la richiesta. Attendere la risposta dal webserver...
 
==== HEAD / HTTP/1.0 ====
Risulta allo stesso modo molto comodo effettuare la richiesta <code>HEAD</code> del protocollo che restituisce le sole intestazioni con:
 
<syntaxhighlight lang="http">
HEAD / HTTP/1.0
</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]];
* [[autenticazione]] del server;
* autenticazione dell'utente.
 
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:
* ''[[Smooth Streaming]]'', ideato da Microsoft<ref>[https://download.microsoft.com/download/4/2/4/4247C3AA-7105-4764-A8F9-321CB6C765EB/IIS_Smooth_Streaming_Technical_Overview.pdf IIS Smooth Streaming Technical] {{webarchive|url=https://web.archive.org/web/20110605002108/http://download.microsoft.com/download/4/2/4/4247C3AA-7105-4764-A8F9-321CB6C765EB/IIS_Smooth_Streaming_Technical_Overview.pdf |data=5 giugno 2011 }}</ref><ref>[http://www.iis.net/download/smoothstreaming Smooth Streaming]</ref>
* ''[[HTTP Dynamic Streaming]]'' soluzione ideata da Adobe
* ''[[HTTP Live Streaming]]'' soluzione ideata da Apple
* ''[[Octoshape]]'' è una piattaforma proprietaria di streaming multimediale, che utilizza la tecnologia per offrire un [[throughput]] migliore e rompere la congestione nell'[[ultimo miglio]]. Ha la possibilità di utilizzare una suite di tecnologie [[multicast]] per ridurre al minimo la larghezza di banda per qualsiasi [[Content Delivery Network|CDN]], [[Internet Service Provider|ISP]], emittente o del fornitore dell'ultimo miglio.
 
Per contro queste soluzioni sono notevolmente più complesse rispetto alle tradizionali tecnologie di streaming. Alcune delle considerazioni documentate riguardano lo stoccaggio, i costi aggiuntivi per la codifica e la difficoltà nel mantenimento della qualità globale. Ci sono state anche alcune dinamiche interessanti trovate intorno alle interazioni complesse fra logica adattiva bit rate in competizione con complessa logica di controllo del flusso TCP.<ref>[http://www.cc.gatech.edu/~sakhshab/Saamer_MMSys11.pdf An Experimental Evaluation of Rate-Adaptation Algorithms in Adaptive Streaming over HTTP] {{webarchive|url=https://web.archive.org/web/20111017140109/http://www.cc.gatech.edu/~sakhshab/Saamer_MMSys11.pdf |data=17 ottobre 2011 }}</ref><ref>{{Cita web |url=http://www.fierceonlinevideo.com/story/adaptive-bit-rate-yellow-brick-road-or-fools-gold-hd-streaming/2011-01-28 |titolo=Is adaptive bit rate the yellow brick road, or fool's gold for HD streaming? |accesso=20 settembre 2011 |urlarchivio=https://web.archive.org/web/20110907004353/http://www.fierceonlinevideo.com/story/adaptive-bit-rate-yellow-brick-road-or-fools-gold-hd-streaming/2011-01-28 |dataarchivio=7 settembre 2011 |urlmorto=sì }}</ref>
 
== Note ==
<references />
 
== Bibliografia ==
* 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]]
* [[SPDY]]
* [[World Wide Web Consortium]]
 
== 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à}}
[[Categoria:Protocolli di rete]]
{{Portale|internet|telematica}}
[[Categoria:Acronimi]]
 
[[Categoria:Hypertext Transfer Protocol| ]]
[[ca:HTTP]]
[[cs:HTTP]]
[[da:HTTP]]
[[de:Hypertext Transfer Protocol]]
[[en:HyperText Transfer Protocol]]
[[eo:Hiperteksto-Transiga Protokolo]]
[[es:HTTP]]
[[et:Hypertext Transfer Protocol]]
[[fi:HTTP]]
[[fr:Hypertext Transfer Protocol]]
[[he:HTTP]]
[[hu:HTTP]]
[[id:HTTP]]
[[ja:Hypertext Transfer Protocol]]
[[ko:HTTP]]
[[lt:HTTP]]
[[lv:HTTP]]
[[nl:Hypertext Transfer Protocol]]
[[nn:Hypertext Transfer Protocol]]
[[no:HTTP]]
[[pl:HTTP]]
[[pt:Protocolo de Transferência de Hipertexto]]
[[ro:HTTP]]
[[ru:HTTP]]
[[sk:Hypertext Transfer Protocol]]
[[sl:HTTP]]
[[sv:HTTP]]
[[th:HyperText Transfer Protocol]]
[[tl:HTTP]]
[[tr:HTTP]]
[[zh:超文本传输协议]]