La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

IL PROTOCOLLO HTTP. UNA PANORAMICA DI HTTP LHTTP(Hypertext Transfer Protocol) è il protocollo dello strato dellapplicazione del Web e ne costituisce il.

Presentazioni simili


Presentazione sul tema: "IL PROTOCOLLO HTTP. UNA PANORAMICA DI HTTP LHTTP(Hypertext Transfer Protocol) è il protocollo dello strato dellapplicazione del Web e ne costituisce il."— Transcript della presentazione:

1 IL PROTOCOLLO HTTP

2 UNA PANORAMICA DI HTTP LHTTP(Hypertext Transfer Protocol) è il protocollo dello strato dellapplicazione 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. LHTTP 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.

3 Quando un utente richiede una pagina, il browser invia messaggi di richiesta allHTTP 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 questultima è 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.

4 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 allHTTP. Questo implica che sia il messaggio di richiesta allHTTP 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, lHTTP è detto protocollo senza stato( stateless protocol).

5 PC su cui funziona Explorer Server su cui funziona il server Web NCSA Richiesta HTTP Mac su cui funziona Navigator Risposta HTTP Richiesta HTTP Comportamento richiesta-risposta dellHTTP

6 IL PROTOCOLLO HTTP Esistono due versioni del protocollo HTTP: HTTP(versione 1.0) HTTP(versione 1.1)

7 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 : Ecco ciò che accade:

8 1.Il client HTTP inizia una connessione TCP a server 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 lHTTP. 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 loggetto allinterno di un messaggio di risposta HTTP e invia il messaggio di risposta al client attraverso il socket.

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

10 I problemi della versione 1.0 Una caratteristica dellHTTP 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.

11 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, laltro per richiedere e ricevere un oggetto. Infine ogni oggetto è sottoposto a una partenza lenta, perché ogni connessione TCP comincia con una fase lenta.

12 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. Unaltro 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 lindirizzo è 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 laumento del traffico di rete.

13 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 sullidentica connessione. In particolare, un intera pagina Web (nellesempio 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. HTTP/1.1

14 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 nellesempio precedente) riportano un RTT relativo alla richiesta e alla ricezione delloggetto. Sebbene questo sia un miglioramento rispetto ai due RTT della connessione non permanente, il ritardo RTT può essere ancora ridotto con l incanalamento.

15 Un altro svantaggio della mancanza dincanalamento è che dopo che il server ha spedito un oggetto sulla connessione TCP permanente, la connessione resta agganciata in attesa dellarrivo di unaltra richiesta;questo comporta spreco delle risorse del server. Di default lHTTP/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 lincanalamento).

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

17 La connessione è attiva sino a quando non viene esplicitamente chiusa da una delle due parti tramite lavvio di un apposito Connection Header, per lappunto 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 linvio 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.

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

19 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: Nella prima riga viene specificato luso 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.

20 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

21 Messaggio di richiesta HTTP Questo che segue è un tipico messaggio di richiesta HTTP: GET/ somedir/ page.html HTTP/ 1.1 Host: 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.

22 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 loggetto richiesto identificato nel campo URL. Ora guardiamo le linee di intestazione dellesempio.

23 La linea di intestazione Host :www.someschool.edu specifica lhost su cui loggetto 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 delloggetto richiesto. La linea di intestazione dellUser-agent: specifica lagente dellutente, che è il tipo di browser che sta facendo la richiesta al server.Qui lagente dellutente è Mozilla/4.0, un browser Netscape. Infine lintestazione Accept-language: indica che lutente preferisce ricevere una versione delloggetto in francese, se un simile oggetto esiste nel server; altrimenti, il server potrà inviare la sua versione di default.

24 Formato generale di un messaggio di richiesta Linea di richiestaMetodo sp URL sp Versionerc lf campo nome intestazione valore rc lf campo nome intestazione valore rc lf rclf Corpo dellentità Linee di intestazione....

25 Messaggio di risposta HTTP Questo messaggio di risposta può essere la risposta al messaggio di richiesta visto in precedenza. HTTP/ OK Connection: close Date: Thu, 06 Aug :00:15 GMT Server: Apache/ (Unix) Last-Modified: Mon,22 Jun :23:24 GMT Content-Length: 6821 Content-type: text/html (dati dati dati dati dati …)

26 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 dellentità(entity body). Questultimo è il nucleo del messaggio e contiene loggetto 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, loggetto richiesto.

27 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 lora 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 lora e la data del momento della creazione o dellultima modifica delloggetto.

28 La linea di intestazione Content-Length: indica il numero di byte delloggetto da spedire. La linea di intestazione Content-Type: indica che loggetto nel corpo dellentità è testo HTML.

29 Formato generale di un messaggio di risposta sp fraserc lf campo nome intestazione valore rc lf campo nome intestazione valore rc lf crlf Corpo dellentità Linee di intestazione.... Linea di stato codice di stato versione

30 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 dellidentità degli utenti. LHTTP fornisce due meccanismi per aiutare il server a identificare gli utenti: autenticazione cookie

31 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). LHTTP fornisce speciali codici di stato e intestazioni per favorire i siti nelleseguire lautenticazione. 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 allutente lautorizzazione. Il client prima invia un messaggio di richiesta ordinario senza alcuna linea di intestazione particolare.

32 Il server allora risponde con un corpo dellentità vuoto e con un codice dello stato 401 Authorization Required. In questo messaggio di risposta il server include lintestazione www-Authenticate: che specifica i dettagli su come eseguire lautenticazione.(Di solito, indica che lutente deve fornire un username e una password). Il client riceve il messaggio di risposta e suggerisce allutente 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.

33 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:

34 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 dellhost del server associato al numero di identificazione dellutente. Nelle richieste successive allo stesso server, diciamo una settimana dopo, il client include unintestazione di richiesta Cookie: e questa intestazione specifica il numero di identificazione di quel server. Nellesempio corrente, il messaggio di richiesta comprende la linea di intestazione: Cookie:

35 In questo modo, il server non conosce lusarname dellutente, 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 lautenticazione 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 lacquirente sta comprando, cioè, per creare una scheda dacquisto virtuale.

36 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.Figura 1.0 Una volta configurato un browser, ciascuna richiesta del browser per un oggetto è prima indirizzata alla cache.

37 Per esempio supponiamo che il browser stia chiedendo loggetto http//www.someschool.edu / campus.gif. il browser stabilisce una connessione TCP con la cache del Web e invia una richiesta HTTP per loggetto alla cache del Web. la cache controlla se ha una copia delloggetto memorizzata localmente. Se cè, la cache inoltra loggetto allinterno di un messaggio di risposta HTTP al browser del client. se la cache non ha loggetto, apre una connessione TCP al server di origine, cioè, a La cache invia allora una richiesta HTTP per loggetto nella connessione TCP.Dopo aver ricevuto questa richiesta, il server originale invia loggetto allinterno di una risposta HTTP alla cache.

38 Quando la cache riceve loggetto, ne archivia una copia nella memoria locale e invia la copia, allinterno 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.

39 Secondo, la cache può ridurre il traffico su un link di accesso Internet di una istituzione. Attraverso la riduzione del traffico, listituzione(per esempio una società o ununiversità) non deve rinnovare la larghezza di banda così spesso, e quindi riduce i costi. Inoltre, la cache può ridurre in modo consistente il traffico dellintero Internet, migliorando quindi le performance di tutte le applicazioni.

40 La gestione della cache Il campo dove si sono compiuti gli sforzi maggiori nella definizione dellHTTP versione 1.1 è la gestione della cache. Lobiettivo è quello di ridurre al minimo il traffico di rete e garantire la sicurezza del contenuto della cache, in modo tale da consentirne luso alle applicazioni senza che lutente rischi di avere informazioni non aggiornate. Il primo passo è stato definire la validità di ogni risorsa, grazie alluso di un nuovo response header: Expires: Thu, 01 Dec :00:00 GMT

41 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: If-modified-since: Thu, 01 Dec : 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.

42 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/ OK Date: Mon, 11 May :35:12 GMT Server:Apache/ Last-Modified: Sun, 10 May :11:27 GMT Expires: Mon, 18 May :35:12 GMT

43 Content-Length: Content-Type: text/ html Con questo header ci indica che la pagina sarà valida ancora per sette giorni.

44 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 dellistituzione non contiene loggetto richiesto, essa invia la richiesta HTTP alla cache nazionale. La cache nazionale invia quindi loggetto (allinterno di un messaggio di risposta HTTP) alla cache dellistituzione, 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.

45 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

46 Uno strong validator identifica univocamente una risorsa, cambia ogni volta che essa cambia e viene realizzato attraverso lheader ETag: ETag: 0-17c3-3293cb4e ETag, che sta per Entity Tag, è un identificativo assegnato alla risorsa dal server. Attraverso lidentificativo il server risale allesatta 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.

47 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

48 Questi due nuovi header,da usare con Entity Tag, rendono la richiesta condizionale; una richiesta di questo tipo: GET http: // index.html HTTP/1.0 Host: If -match: 0-17c3-3293cb4e verrà soddisfatta solo se lentity tag della risorsa richiesta corrisponde con quello specificato,mentre la richiesta: GET http: // index.html HTTP/1.0 Host: If-none-match: 0-17c3-3293cb4e verrà soddisfatta solo se lentity tag è variato.

49 Nuovi comandi NellHTTP 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.

50 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: otterremo la seguente risposta: HTTP/ ok Date: Mon, 22 Jun :34:18 GMT0 Server: Apache/ Content-Length: 0 Allow: GET, HEAD, OPTIONS, TRACE

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

52 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.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/ OK Date: Mon, 11 May :35:12 GMT Server: Apache / Warning: 10, Origin server was not contacted Content-Length: Content-Type: text/html

53 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.Tabella 2.

54 Nuovi codici di stato del protocollo HTTP1.1 Codice Descrizione 100 Il client può continuare linvio della richiesta. 101 Il server è disponibile ad effettuare un cambio di protocollo. 205 Il completamento della risposta richiede laggiornamento 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 dallheader Location. 402 Laccesso 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 Laccesso 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 lheader 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 dellURL eccede i limiti consentiti dal server.

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

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

57 Richiesta di oggetti attraverso una cache del Web Client Server di origine Server di origine Proxy server


Scaricare ppt "IL PROTOCOLLO HTTP. UNA PANORAMICA DI HTTP LHTTP(Hypertext Transfer Protocol) è il protocollo dello strato dellapplicazione del Web e ne costituisce il."

Presentazioni simili


Annunci Google