IL PROTOCOLLO HTTP

IL PROTOCOLLO HTTP
UNA PANORAMICA DI HTTP
L’HTTP(Hypertext Transfer Protocol) è il protocollo dello
strato dell’applicazione del Web e ne costituisce il suo
cuore.Questo protocollo è implementato in due programmi: un
programma client e uno server.Questi programmi sono eseguiti
da due diversi terminali e parlano tra loro scambiandosi
messaggi HTTP. L’HTTP definisce la struttura di questi
messaggi e il modo in cui client e server se liscambiano.
Inoltre definisce come i client Web(cioè,i browser) richiedono
le pagine Web dai server(cioè, i server Web) e come i server
trasferiscono le pagine Web ai client.
Quando un utente richiede una pagina, il browser invia
messaggi di richiesta all’HTTP per gli oggetti nella pagina al
server.Il server riceve la richiesta e risponde con messaggi di
risposta HTTP contenenti gli oggetti.
Il protocollo HTTP usa il TCP come protocollo di trasporto di
base.
Il client HTTP dapprima inizia una connessione TCP con il
server e quando quest’ultima è stabilita i processi di browser e
server accedono al TCP attraverso i loro socket di interfaccia.
Il client invia messaggi di richiesta HTTP nel suo socket di
interfaccia e da questo riceve messaggi di risposta HTTP.
In modo analogo, il server HTTP riceve messaggi dal suo
socket di interfaccia e invia messaggi di risposta nel suo
socket di interfaccia.
Una volta che il client ha iviato un messaggio nel suo socket di
interfaccia il messaggio è nelle mani del TCP che fornisce un
affidabile trasferimento dei dati all’HTTP.
Questo implica che sia il messaggio di richiesta all’HTTP
emesso dal processo di un client, sia il mesaggio di risposta
HTTP emesso dal processo del server arrivano intatti alla loro
destinazione.
Poiché un server HTTP non conserva le informazioni relative
ai client, l’HTTP è detto protocollo senza stato( stateless
protocol).
Comportamento richiesta-risposta dell’HTTP
Richiesta HTTP
Richiesta HTTP
Risposta HTTP
Risposta HTTP
PC su cui
funziona Explorer
Server
su cui funziona
il server Web
NCSA
Mac su cui funziona
Navigator
IL PROTOCOLLO HTTP
Esistono due versioni del protocollo HTTP:
• HTTP(versione 1.0)
• HTTP(versione 1.1)
HTTP/1.0
Il protocollo HTTP/1.0 utilizza una connessione non
permanente cioè una connessione che si chiude dopo che il
server ha inviato gli oggetti.
Seguiamo i passi per il trasferimento di una pagina Web dal
server al client.
Supponiamo che la pagina consista di un file base HTLM e di
10 immagini JPEG, e che tutti questi 11 oggetti risiedano sullo
stesso server.Assumiamo che l’ indirizzo URL per il file base
sia :
www.someSchool.edu/someDepartment/home.index.
Ecco ciò che accade:
1. Il client HTTP inizia una connessione TCP a server
www.someSchool.edu.
La porta numero 80 e usata come numero di default della
porta a cui il server HTTP ascolterà i client HTTP che
vogliono recuperare i documenti usando l’HTTP.
2. Il client HTTP invia un messaggio di richiesta HTTP al
server attraverso il socket associato alla connessione TCP
che è stata stabilita in 1.Il messaggio di richiesta include il
nome del percorso /someDepartment/home.index.
3. Il server HTTP riceve il messaggio di richiesta attraverso
il sochet associato alla connessione stabilita al punto
1,trova l’ oggetto/someDepartment/home.index nel sito in
cui è immagazzinato(RAM o disco), incapsula l’oggetto
all’interno di un messaggio di risposta HTTP e invia il
messaggio di risposta al client attraverso il socket.
4. Il server HTTP dice al TCP di concludere la connessione
TCP.(Ma il TCP non può chiudere realmente la
connessione finchè il client non ha ricevuto il messaggio
di risposta intatto.)
5. Il client HTTP riceve il messaggio di risposta.La
connessione TCP si conclude.Il messaggio indica che
l’oggetto incapsulato è un file HTML.Il client estrae il file
dal messaggio di risposta, analizza il file HTML e trova i
riferimenti ai 10 oggetti JPEG.
6. I primi quattro passi vengono quindi ripetuti per ciascuno
degli oggetti JPEG cui si fa riferimento.
I problemi della versione 1.0
Una caratteristica dell’HTTP 1.0 è la semplicità, e proprio
questa ne costituisce il punto debole:ogni connessione esiste
solo per il tempo necessario ad effettuare il trasferimento di
una risorsa.
Questo tipo di connessione potrebbe sembrare vantaggiosa, ma
il problema nasce quando si vogliono scaricare più risorse in
sequenza dallo stesso sito.
Per esempio se la pagina richiesta include una decina di
immagini e un sottofondo musicale si devono stabilire tante
connessioni quante sono le risorse richieste.
Questo è uno spreco,tenendo conto che la maggior parte del
tempo viene speso per stabilire la connessione.
Per ciascuna di queste connessioni devono essere allocati i
buffer del TCP e le variabili del TCP devono essere conservate
sia nel client sia nel server.
Questo può caricare in modo serio il server Web, che potrebbe
dover smaltire simultaneamente le richieste di centinaia di
client.Secondo ogni oggetto richiesto subisce due RTT
(“Round-Trip Time” che è il tempo occorrente a un piccolo
pacchetto per viaggiare dal client al server e ritornare al
client): uno per stabilire la connessione TCP, l’altro per
richiedere e ricevere un oggetto.
Infine ogni oggetto è sottoposto a una partenza lenta, perché
ogni connessione TCP comincia con una fase lenta.
Visto che la dimensione dei file da trasferire va sempre
crescendo,la maggior parte dei trasferimenti non va a buon
fine.
Quindi è stato necessario effettuare trasferimenti parziali in
modo tale che in caso di interruzione si può riprendere il
download dal punto dove si era interrotto.
Un’altro problema è la diffusione del NON-IP Virtual Hosting,
che consiste nel mantenere più server sulla stessa macchina,
con un solo indirizzo IP, differenziandoli in base al loro
hostname apparente-apparente perché di fatto l’indirizzo è solo
uno.
Inoltre, i meccanismi di controllo della cache implementati in
questa versione sono rudimentali per cui spesso le applicazioni
invece di rischiare di fornire dei dati non aggiornati , non
impiegavano la cache,causando l’aumento del traffico di rete.
HTTP/1.1
Il protocollo HTTP/1.1 utilizza una connessione permanente.
Con la connessione permanente, il server lascia aperta la
connessione TCP dopo aver spedito la risposta e quindi le
successive richieste e risposte fra gli stessi client e server
possono essere inviate sull’identica connessione.
In particolare, un intera pagina Web (nell’esempio precedente
il file base HTML e 10 immagini JPEG) può essere spedita su
una singola connessione TCP permanente :inoltre, pagine Web
multiple residenti sullo stesso server possono essere spedite
sulla stessa connessione TCP permanente.
Esistono due versioni della connessione permanente:
» connessione non incanalata
» connessione incanalata
Nella prima il client passa una nuova richiesta solo quando la
risposta alla precedente è stata ricevuta.
In questo caso ciascuno degli oggetti a cui si rimanda (le dieci
immagini nell’esempio precedente) riportano un RTT relativo
alla richiesta e alla ricezione dell’oggetto.
Sebbene questo sia un miglioramento rispetto ai due RTT della
connessione non permanente, il ritardo RTT può essere ancora
ridotto con l’ incanalamento.
Un’ altro svantaggio della mancanza d’incanalamento è che
dopo che il server ha spedito un oggetto sulla connessione TCP
permanente, la connessione resta agganciata in attesa
dell’arrivo di un’altra richiesta;questo comporta spreco delle
risorse del server.
Di default l’HTTP/1.1 utilizza la connessione permanente con
incanalamento.In questo caso, il client HTTP può fare richieste
consecutive(back-to-back)per gli oggetti in riferimento.
Quando il server riceve le richieste può inviare gli oggetti
back to back.
Se tutte le richieste e tutte le risposte sono inviate back to
back, allora si impiega un solo RTT per tutti gli oggetti in
riferimento(invece di un RTT per ogni oggetto in riferimento
quando non si usa l’incanalamento).
Inoltre la connessione TCP incanalata resta agganciata per una
frazione di tempo più piccola .
Oltre alla riduzione del ritardo RTT la connessione
permanente(con o senza incanalamento) ha un ritardo per
partenza lenta più piccolo rispetto alla connessione non
permanente.
Il motivo è che dopo la spedizione del primo oggetto, il server
della connessione permanente , finchè continua ad usare la
stessa connessione TCP , non deve spedire gli oggetti
successivi alla basa velocità iniziale ma può riprendere alla
velocità con cui l’ ha lasciato il primo oggetto.
La connessione è attiva sino a quando non viene
esplicitamente chiusa da una delle due parti tramite l’avvio di
un apposito Connection Header, per l’appunto Connection:
Connection: close
che a seconda dei casi fa parte della richiesta se il client decide
se la connessione deve essere chiusa dal server subito dopo
l’invio dei dati, o della risposta se il server decide di chiudere
la connessione una volta terminato il trasferimento.
La connessione permanente di effettuare il pipeling delle
richieste cioè di inviarne una sequenza senza attendere le
risposte del server che dovrà inviare i dati nello stesso ordine
in cui sono stati chiesti.
Ogni client che vuole effettuare pipeling deve essere in
condizione di gestire le possibili situazioni di errore.
Ad esempio, il server potrebbe chiudere la connessione dopo
aver inviato solo la prima risposta.
In questo caso, il client dovrà porsi il dubbio che il server non
supporti le connessioni permanenti e quindi dovrà ripetere
l’invio delle richieste separatamente.
Oppure la connessione potrebbe interrompersi prima che tutte
le risposte siano arrivate, e in questo caso il client dovrà
ripetere tutte le richieste.
Richieste più chiare
Per risolvere i problemi causati dal Virtual Hosting è stato
introdotto un nuovo request header;questo header che deve
essere incluso in ogni richiesta, specifica quale è il server che
intendiamo contattare e su quale porta.
Per esempio se vogliamo contattare il sito di Infomedia sulla
porta 8080 ,vediamo come si compone la richiesta:
GET / index.html HTTP/1.1
User-agent: Mozilla 3.01C
Accept: image/gif, image/ x- xbi tmap, image/ jpeg,*/*
Host: www.infomedia.it:8080
Nella prima riga viene specificato l’uso della versione 1.1 del
protocollo, mentre nella seconda il request header Host riporta
il nome del server che si intende contattare e la porta.
IL FORMATO DEL MESSAGGIO HTTP
Le specifiche HTTP 1.0 ([RFC 1945] e 1.1[RFC 2616]
definiscono i formati del messaggi HTTP.
Ci sono due tipi di messaggio HTTP:
‫ ٭‬messaggi d richiesta
‫ ٭‬messaggi di risposta
Messaggio di richiesta HTTP
Questo che segue è un tipico messaggio di richiesta HTTP:
GET/ somedir/ page.html HTTP/ 1.1
Host: www.someschool.edu
Connection: close
User-agent: Mozilla/ 4.0
Accept-language: fr
(ritorno carrello extra, line feed)
Prima di tutto vediamo che il messaggio è scritto in testo
ASCII normale in modo tale che il nostro computer ordinario
può leggerlo.
Secondo vediamo che il messaggio è costituito da cinque linee,
ciascuna seguita da un ritorno carrello e da un line feed
(un unico carattere usato per separare le righe di testo).
La prima linea di un messaggio di richiesta HTTP è detta linea
di richiesta(request line); le linee seguenti sono dette linee di
intestazione(header line).
La linea di richiesta ha tre campi:il campo metodo, il campo
URL e il campo versione dell’ HTTP.Il campo metodo può
assumere molti diversi valori, compresi GET, POST, e HEAD.
La maggior parte dei messaggi di richiesta HTTP usa il
metodo GET.
Questo metodo viene usato quando il browser richiede un
oggetto, con l’oggetto richiesto identificato nel campo URL.
Ora guardiamo le linee di intestazione dell’esempio.
La linea di intestazione Host :www.someschool.edu
specifica l’host su cui l’oggetto risiede.
Includendo la linea di intestazione Connection: il browser
sta dicendo al server che non vuole usare la connessione
permanente ma vuole che esso chiuda la connessione dopo
la spedizione dell’oggetto richiesto.
La linea di intestazione dell’User-agent: specifica l’agente
dell’utente, che è il tipo di browser che sta facendo la
richiesta al server.Qui l’agente dell’utente è Mozilla/4.0 ,
un browser Netscape.
Infine l’intestazione Accept-language: indica che l’utente
preferisce ricevere una versione dell’oggetto in francese,
se un simile oggetto esiste nel server; altrimenti, il server
potrà inviare la sua versione di default.
Formato generale di un messaggio di richiesta
Metodo sp
campo nome
intestazione
campo nome
intestazione
rc
sp
URL
.
. valore
Versione
rc
lf Linea di richiesta
lf
•
•
•
.
.
rc
Linee di intestazione
valore
rc
lf
lf
Corpo
dell’entità
Messaggio di risposta HTTP
Questo messaggio di risposta può essere la risposta al
messaggio di richiesta visto in precedenza.
HTTP/1.1 200 OK
Connection: close
Date: Thu, 06 Aug 1998 12:00:15 GMT
Server: Apache/ 1.3.0 (Unix)
Last-Modified: Mon ,22 Jun 1998 09:23:24 GMT
Content-Length: 6821
Content-type: text/html
(dati dati dati dati dati …)
Questo messaggio di risposta è suddiviso in tre parti:una linea
iniziale detta linea di stato(status line), sei linee di
intestazione(header line),e un corpo dell’entità(entity body).
Quest’ultimo è il nucleo del messaggio e contiene l’oggetto
richiesto(rappresentato da dati dati dati dati dati …).
La linea di stato ha tre campi:
 versione del protocollo
 codice di stato
messaggio di stato
In questo esempio , la linea di stato indica che il server sta
usando HTTP/1.1 e che ha trovato, e sta inviando, l’oggetto
richiesto.
Adesso guardiamo le linee di intestazione.
Il server usa la linea di intestazione Connection: close per
avvisare il client che chiuderà la connessione TCP al termine
della spedizione del messaggio.
La linea di intestazione Date: indica l’ora e la data del
momento in cui la risposta HTTP è stata creata e spedita dal
server.
La linea di intestazione Server: indica che il messaggio è stato
generato da un Web Apache; è analoga alla linea di
intestazione User-agent: nel messaggio di richiesta HTTP.
La linea di intestazione Last-Modified: indica l’ora e la data
del momento della creazione o dell’ultima modifica
dell’oggetto.
La linea di intestazione Content-Length: indica il numero di
byte dell’oggetto da spedire.
La linea di intestazione Content-Type: indica che l’oggetto
nel corpo dell’entità è testo HTML.
Formato generale di un messaggio di risposta
codice
versione sp
sp
di stato
campo nome .
. valore
intestazione
frase
rc
cr
.
.
lf
Linea di stato
lf
•
•
•
campo nome
intestazione
rc
Linee di intestazione
valore
rc
lf
lf
Corpo
dell’entità
INTERAZIONE USER-SERVER:
AUTENTICAZIONE E COOKIE
Spesso si desidera che un sito Web possa identificare gli
utenti, sia perché il server vuole limitare gli accessi, sia
perché vuole dispensare i contenuti in funzione dell’identità
degli utenti.
L’HTTP fornisce due meccanismi per aiutare il server a
identificare gli utenti:
 autenticazione
 cookie
Autenticazione
Molti siti richiedono agli utenti di fornire un username
(nome utente) e una password per poter accedere ai
documenti archiviati sul server.A questi requisiti si ci
riferisce come autenticazione(authentication).
L’HTTP fornisce speciali codici di stato e intestazioni per
favorire i siti nell’eseguire l’autenticazione.
Vediamo un esempio per capire come lavorano questi
speciali codici di stato e le intestazioni.
Supponiamo che un client richiede un oggetto a un server e
che il server richieda all’utente l’autorizzazione.
Il client prima invia un messaggio di richiesta ordinario
senza alcuna linea di intestazione particolare.
Il server allora risponde con un corpo dell’entità vuoto e con
un codice dello stato 401 Authorization Required.
In questo messaggio di risposta il server include
l’intestazione www-Authenticate: che specifica i dettagli su
come eseguire l’autenticazione.(Di solito, indica che
l’utente deve fornire un username e una password).
Il client riceve il messaggio di risposta e suggerisce
all’utente di inserire username e password.
Il client rispedisce il messaggio di richiesta, ma questa volta
include una linea di intestazione Authorization:completa di
username e password.
Dopo aver ottenuto il primo oggetto, il client continua ad
inviare username e password nelle successive richieste di
oggetti al server finchè esce dal browser.
Cookie
I cookie sono un meccanismo alternativo che possono usare
i siti per tener traccia degli utenti.
Vediamo un esempio.
Supponete che un cliente contatti un sito Web per la prima
volta, e che per questo sito usi i cookie. La risposta del
server includerà una intestazione Set-cookie: Spesso questa
linea di intestazione contiene un numero di identificazione
generato dal server Web.
Per esempio la linea di intestazione può essere:
Set-cookie: 1678453
Quando il client HTTP riceve il messaggio di risposta vede
la linea di intestazione Set-cookie: e il numero di
identificazione. Esso allora appende una linea a uno speciale
file cookie che è immagazzinato nella macchina client.
Questa linea di solito comprende il nome dell’host del
server associato al numero di identificazione dell’utente.
Nelle richieste successive allo stesso server, diciamo una
settimana dopo, il client include un’intestazione di richiesta
Cookie: e questa intestazione specifica il numero di
identificazione di quel server. Nell’esempio corrente, il
messaggio di richiesta comprende la linea di intestazione:
Cookie: 1678453
In questo modo, il server non conosce l’usarname
dell’utente, ma sa che questo utente è lo stesso che ha fatto
una specifica richiesta una settimana prima.
I sever Web usano i cookie per molti scopi diversi:
se il serve richiede l’autenticazione ma non vuole assillare
un utente richiedendogli di sottoporre username e password
tutte le volte che visita il sito, esso può impostare un cookie.
se un server vuole memorizzare le preferenze di un utente
così da potergli fornire pubblicità mirata durante le visite
successive, esso può impostare un cookie:
se un utente sta acquistando in un sito (per esempio, alcuni
CD), il server può usare i cookie per conservare traccia degli
oggetti che l’acquirente sta comprando, cioè, per creare una
scheda d’acquisto virtuale.
LA CACHE DEL WEB
La cache del Web(detta anche proxy server) è un entità
della rete che soddisfa le richieste HTTP da parte di un
client.
La cache del Web ha un proprio disco di archiviazione e
conserva nella sua memoria copie degli oggetti richiesti di
recente.
Come illustrato in Figura 1.0 gli utenti configurano i loro
browser così che tutte le loro richieste HTTP siano prima
dirette alla cache.
Una volta configurato un browser, ciascuna richiesta del
browser per un oggetto è prima indirizzata alla cache.
Per esempio supponiamo che il browser stia chiedendo
l’oggetto http//www.someschool.edu / campus.gif.
•il browser stabilisce una connessione TCP con la cache del
Web e invia una richiesta HTTP per l’oggetto alla cache del
Web.
• la cache controlla se ha una copia dell’oggetto memorizzata
localmente.
Se c’è, la cache inoltra l’oggetto all’interno di un messaggio
di risposta HTTP al browser del client.
• se la cache non ha l’oggetto, apre una connessione TCP al
server di origine, cioè, a www.someschool.edu.
La cache invia allora una richiesta HTTP per l’oggetto nella
connessione TCP.Dopo aver ricevuto questa richiesta, il
server originale invia l’oggetto all’interno di una risposta
HTTP alla cache.
•Quando la cache riceve l’oggetto, ne archivia una copia
nella memoria locale e invia la copia, all’interno di un
messaggio di risposta HTTP, al browser del client, al
browser del client.
La cache è sia un server sia un client allo stesso tempo
Quando riceve le richieste e invia le risposte a un browser è
un server.
Quando invia le richieste e riceve le risposte è un client.
Le cache del Web hanno un grande successo in Internet per
almeno tre ragioni.
Primo, una cache può sostanzialmente ridurre il tempo di
risposta a una richiesta del client soprattutto se il collo di
bottiglia della larghezza di banda fra il client e il server di
origine è inferiore a quello tra il client e la cache.
Secondo, la cache può ridurre il traffico su un link di
accesso Internet di una istituzione.
Attraverso la riduzione del traffico, l’istituzione(per
esempio una società o un’università) non deve rinnovare la
larghezza di banda così spesso, e quindi riduce i costi.
Inoltre, la cache può ridurre in modo consistente il traffico
dell’intero Internet, migliorando quindi le performance di
tutte le applicazioni.
La gestione della cache
Il campo dove si sono compiuti gli sforzi maggiori nella
definizione dell’HTTP versione 1.1 è la gestione della
cache.
L’obiettivo è quello di ridurre al minimo il traffico di rete
e garantire la sicurezza del contenuto della cache, in
modo tale da consentirne l’uso alle applicazioni senza
che l’utente rischi di avere informazioni non aggiornate.
Il primo passo è stato definire la validità di ogni risorsa,
grazie all’uso di un nuovo response header:
Expires: Thu, 01 Dec 1994
16:00:00 GMT
Il response header dà un indicazione diretta della data oltre
la quale il dato in cache non sarà più affidabile.
Prendiamo come esempio la seguente richiesta:
GET /index.html HTTP/ 1.1
User-Agent: Mozilla 3. 01C
Accept: image/ gif , image / x-xbitmap ,image/ jpeg, */*
Host: www.infomedia.it
If-modified-since: Thu , 01 Dec 1994 16: 00: 00 GMT
Supponiamo che la pagina sul server sia stata modificata il
primo gennaio del 1998 ma che la richiesta passi tramite un
proxy che ne ha una versione aggiornata al primo gennaio
1997.
Mentre con la versione 1.0 avremmo ricevuto la copia del
proxy, con la versione 1.1 quello che riceveremo dipenderà
dalla data dalla data di scadenza della pagina:se la data
lascia una settimana di validità , il proxy si accorgerà di
avere una copia ormai scaduta e la richiederà
automaticamente al server.
Ricevuta la pagina aggiornata la memorizzerà nella sua
cache e c’è la invierà con un header di questo tipo:
HTTP/ 1.1 200 OK
Date: Mon, 11 May 1998 15:35:12 GMT
Server:Apache/ 1.2.4
Last-Modified: Sun, 10 May 1998 18:11:27 GMT
Expires: Mon, 18 May 1998 15:35:12 GMT
Content-Length: 16225
Content-Type: text/ html
Con questo header ci indica che la pagina sarà valida ancora
per sette giorni.
Caching cooperativo
Utilizzando cache Web multiple, situate in diversi posti in
Internet, è possibile cooperare e migliorare le performance
generali.
Per esempio, la cache di una istituzione può essere
configurata per inviare le sue richieste HTTP a una cache in
una colonna portante di ISP a livello nazionale.In questo
caso, quando la cache dell’istituzione non contiene l’oggetto
richiesto, essa invia la richiesta HTTP alla cache nazionale.
La cache nazionale invia quindi l’oggetto (all’interno di un
messaggio di risposta HTTP) alla cache dell’istituzione, che
a sua volta lo inoltra al browser richiedente.
I vantaggi di passare attraverso una cache di più alto livello,
come una nazionale, e che ha molti più utilizzatori e quindi
maggiori hit rate.
I validators
Il compito dei validators(validatori) è quello di ridurre ai
minimi termini il dialogo.
Essi vengono generati dal server al momento della risposta
e utilizzati dai client per operazioni di matching.
Esistono due tipi di validators:
 strong validators
 weak validators
Uno strong validator identifica univocamente una risorsa,
cambia ogni volta che essa cambia e viene realizzato
attraverso l’header ETag:
ETag: “ 0-17c3-3293cb4e”
ETag, che sta per Entity Tag, è un identificativo assegnato
alla risorsa dal server.
Attraverso l’identificativo il server risale all’esatta versione
della risorsa e, se è stata aggiornata, effettua il trasferimento
includendo il nuovo Entity Tag; se invece la risorsa è ancora
valida, la risposta consiste nel solo codice di stato 304 – Not
modified.
Un weak validator non sempre cambia al cambiare della
risorsa ed è realizzato tramite il response header LastModified-Date; la convalida avviene confrontando la data
della risorsa in cache con quella della risorsa aggiornata.
Questo validator è definito ‘debole ’perché la sua precisione
massima è pari ad un secondo ed almeno in teoria la risorsa
potrebbe cambiare più volte senza che ce ne accorgiamo.
Attualmente le richieste e le risposte HTTP 1.1 includono
sempre Last-Modified-Date per la massima compatibilità ed
Etag quando la risorsa va identificata con la massima
precisione.
Per ridurre il carico sulla rete, sono stati creati nuovi request
header:
If-match: “0-17c3-3293cb4e”
If-none-match: “0-17c3-3293cb4e”
Questi due nuovi header,da usare con Entity Tag, rendono la
richiesta condizionale; una richiesta di questo tipo:
GET http: // www.infomedia.it/ index .html HTTP/1.0
Host: www.infomedia.it
If -match: “0-17c3-3293cb4e”
verrà soddisfatta solo se l’entity tag della risorsa richiesta
corrisponde con quello specificato,mentre la richiesta:
GET http: // www.infomedia.it/ index .html HTTP/1.0
Host: www.infomedia.it
If-none-match: “0-17c3-3293cb4e”
verrà soddisfatta solo se l’entity tag è variato.
Nuovi comandi
Nell’HTTP 1.1 sono stati aggiunti nuovi comandi:
– Options che permette di ‘interrogare’ un server HTT
sapere quali comandi esso supporta.
– Put che, al pari del suo equivalente FTP, consente di
trasferire una risorsa ad un server HTTP.
– Delete che cancella una risorsa da un server(a patto che si
sia autorizzati a farlo).
– Trace che effettua una sorta di Traceroute attraverso una
serie di proxy/gateway e, per ognuno di essi che supporta
HTTP 1.1, ne riporta le caratteristiche.
Per vedere un esempio di uno di questi comandi, ci
connettiamo ad un server che supporta HTTP 1.1
(www.infomedia.it) ed inviamo il seguente comando:
OPTIONS * HTTP/ 1.1
Host: www.infomedia.it
otterremo la seguente risposta:
HTTP/ 1.1 200 ok
Date: Mon, 22 Jun 1998 21:34:18 GMT0
Server: Apache/ 1.2.1
Content-Length: 0
Allow: GET, HEAD, OPTIONS, TRACE
In questa risposta la lista dei comandi è fornita tramite il
response header Allow.
Quasi tutti i server compatibili HTTP 1.1 supportano
OPTIONS e TRACE, solo pochissimi supportano PUT e
DELETE per motivi di sicurezza.
Nessun browser, al momento, supporta questi comandi e
quindi chi li provare deve connettersi via telnet al server
HTTP e inviarli manualmente.
Codici di stato e warming
Nel protocollo HTTP 1.1 sono stati aggiunti nuovi codici di
stato a quelli gia esistenti che sono riportati nella Tabella 1.
Inoltre per rendere trasparente la gestione della cache è
possibile generare warning con qualsiasi dispositivo
intermedio che partecipi al collegamento fornendo dati alla
propria cache, tramite il response header Warning:
HTTP/1.1 200 OK
Date: Mon, 11 May 1998 15:35:12 GMT
Server: Apache / 1.2.4
Warning: 10, Origin server was not contacted
Content-Length: 16225
Content-Type: text/html
Il warming ci informa che la risorsa è stata prelevata dalla
cache di un proxy intermedio e non dal server originale
perché evidentemente risulta aggiornata.La lista di tutti i
warning previsti da HTTP 1.1è riportata in Tabella 2.
Nuovi codici di stato del protocollo HTTP1.1
Codice Descrizione
100
Il client può continuare l’invio della richiesta.
101
Il server è disponibile ad effettuare un cambio di protocollo.
205
Il completamento della risposta richiede l’aggiornamento della form che ha dato origine alla richiesta.
206
Una richiesta di trasferimento parziale è stata soddisfatta.
303
La risposta alla richiesta può essere trovata ad un diverso indirizzo.
305
La richiesta può essere soddisfatta solo passando tramite il proxy specificato dall’header Location.
402
L’accesso alla risorsa è a pagamento(riservato per uso futuro).
405
La risorsa non può essere acceduta tramite il metodo utilizzato.
406
Il tipo di risposta che il server può generare non è accettabile dal client.
407
L’accesso al proxy è consentito solo ad utenti autorizzati(richiede inserzione username e password).
408
Non è stata ricevuta alcuna risposta entro il tempo limite.
409
La richiesta non può essere soddisfatta a causa di un conflitto.
410
La risorsa non è più disponibile sul server né altrove.
411
Nella richiesta è stato omesso l’header Content-length.
412
Una precondizione specificata in un request header non è stata soddisfatta.
413
La dimensione della richiesta eccede i limiti consentiti dal server.
414
La lunghezza dell’URL eccede i limiti consentiti dal server.
415
Il formato in cui è espressa la richiesta non è supportato dal server.
504
Il server, agendo come gateway o come proxy, non ha ricevuto risposta entro il tempo limite.
505
Il server non supporta la versione del protocollo richiesta.
Codici di warning del protocollo HTTP
Codice Descrizione
10
La validità della risposta è scaduta.
11
è stata fornita una risposta la cui validità è scaduta perché il tentativo di aggiornamento è fallito.
12
La cache non è in comunicazione con il resto della rete.
13
La validità della risposta, stabilita in maniera euristica dalla cache, è scaduta.
14
La risposta ha subito una trasformazione(es. conversione di formato grafico).
99
Warning generico.
Richiesta di oggetti attraverso una cache del Web
Client
Client
Proxy
server
Server
di origine
Server
di origine