HTTP
| Livello Applicazioni | HTTP, SMTP, FTP, DNS, SSH, IRC, SNMP, SIP, RSYNC, Telnet ... |
| Livello di Trasporto | TCP, UDP, SCTP, RTP, DCCP ... |
| Livello di Rete | IPv4, IPv6, ARP, ICMP, IGMP ... |
| Livello Datalink | Ethernet, WiFi , PPP ... |
| Livello Fisico | Ethernet, WiFi , Token ring, FDDI, ... |
HTTP è l'acronimo di HyperText Transfer Protocol (protocollo di trasferimento di un ipertesto). Usato come principale sistema per la trasmissione di informazioni sul web. Le specifiche del protocollo sono attualmente in carica al W3C (World Wide Web Consortium)
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 URL, il nucleo base della "World-Wide Web WWW global information initiative" portata avanti da Tim Berners-Lee al CERN di Ginevra per la condivisione delle informazioni tra la comunità dei fisici delle alte energie. 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.
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. Vi sono quindi due tipi di messaggi HTTP: messaggi richiesta e messaggi risposta.
HTTP differisce da altri protocolli di 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 .
| Indice |
Messaggio di richiesta
Il messaggio richiesta è composto di tre parti:
- Linea di richiesta (request line)
- Sezione Header (informazioni aggiuntive)
- Body (corpo del messaggio)
Linea di richiesta
La linea di richiesta è composta dal metodo, URI e versione del protocollo. Il metodo di richiesta può essere uno dei seguenti
- GET
- POST
- HEADER
- PUT
- DELETE
- TRACE
- CONNECT
l'URI sta per Uniform Resource Identifier ed indica l'oggetto della richiesta (ad esempio la pagina web che si intende ottenere)
I metodi HTTP più comuni sono GET e POST. Il metodo GET è usato per ottenere il contenuto della risorsa indicata come URI (come può essere il contenuto di una pagina HTML). Una richiesta con metodo GET non prevede l'uso del body
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.
Gli header della richiesta
Gli header di richiesta più comuni sono:
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.
User-Agent: Identificazione del tipo di client: tipo browser, produttore, versione...
Messaggio di risposta
Il messaggio di risposta è composto dalle seguenti tre parti:
- Linea di stato (status-line)
- Sezione header
- Body (contenuto della risposta)
Linea di stato
La linea di stato riporta un codice a tre cifre catalogato nel seguento modo:
- 1xx : Informational
- 2xx: Success
- 3xx: Redirection
- 4xx: Client error
- 5xx: Server error
Nel caso più comune il server risponde con un codice 200 (OK) e fornisce contentuto nella sezione body. Altri casi comuni sono:
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.
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.
500 Internal Server Error. Il server non è in grado di rispondere alla richiesta per un suo problema interno.
Gli header della risposta
Gli header della risposta più comuni sono:
- Server. Indica il tipo la marca , la versione del server. Un po' l'equivalente dell'header di richiesta User-Agent
- Content-Type. Indica il tipo di contenuto restituito. La codifica di tali tipi (detti Media type) sono registrati presso IANA (Internet Assigned Number Authority ) e sono detti tipi MIME (Multimedia Internet Message Extensions), la loro codifica è descritta nel documento RFC 1521. I principali sono:
- text/html. Documento HTML)
- text/plaintext. Documento di testo non formattato)
- image/jpeg.Immagine di fromato JPEG
Esempi di messaggi HTTP
Richiesta:
GET /wiki/Pagina_principale HTTP/1.1 Connection: Keep-Alive User-Agent: Mozilla/5.0 (compatible; Konqueror/3.2; Linux) (KHTML, like Gecko) Accept: text/html, image/jpeg, image/png, text/*, image/*, */* 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
Risposta:
HTTP/1.0 200 OK Date: Mon, 28 Jun 2004 10:47:31 GMT Server: Apache/1.3.29 (Unix) PHP/4.3.4 X-Powered-By: PHP/4.3.4 Vary: Accept-Encoding,Cookie Cache-Control: private, s-maxage=0, max-age=0, must-revalidate Content-Language: it Content-Type: text/html; charset=utf-8 Age: 7673 X-Cache: HIT from wikipedia.org Connection: close <HTML> [ ...]
Versioni sicure
Dal momento che tutto il traffico HTTP è anonimo e in chiaro, sono state sviluppate diverse alternative per garantire differenti livelli di sicurezza, in termini di
- cifratura del traffico
- verifica di integrità del traffico
- autenticazione del server
- autenticazione dell'utente
La prima proposta venne direttamente da 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 PEM e chiavi 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 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 cifrato a livello di trasporto mediante SSL o TLS per impedire l'intercettazione di qualsiasi parte della transazione. Entrambe 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.