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:

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. 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.

Il server HTTP dice al TCP di concludere la connessione TCP 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.) 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. 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.

Quando il server riceve le richieste può inviare gli oggetti 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 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 Linea di richiesta Metodo sp URL Versione rc lf campo nome intestazione valore • Corpo dell’entità Linee di intestazione .

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 frase rc lf campo nome intestazione valore • cr Corpo dell’entità Linee di intestazione . Linea di stato codice di stato versione

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

Prendiamo come esempio la seguente richiesta: 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 Last-Modified-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: 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 Proxy server Server di origine Client Client Server di origine