WWW Introduzione al WWW Fabio Vitali Università di Bologna.

Presentazione sul tema: "WWW Introduzione al WWW Fabio Vitali Università di Bologna."— Transcript della presentazione:

1 WWW Introduzione al WWW Fabio Vitali Università di Bologna

2 WWW Fabio Vitali2 Introduzione Oggi esaminiamo: u Una brevissima storia degli ipertesti e del WWW u I tre protocolli principali del WWW F Universal Resource Identifier (URI) e Locator (URL) F Hypertext Transfer Protocol (HTTP) F Hypertext Markup Language (HTML)

3 WWW Fabio Vitali3 Breve storia degli ipertesti n Vannevar Bush e il Memex n Theodore Nelson e Xanadu n Douglas Engelbart e Augment n Bill Atkinson e Hypercard n Tim Berners-Lee e il World Wide Web n NCSA, Marc Andreessen e Mosaic n W3C, Netscape e Microsoft

4 WWW Fabio Vitali4 Cos’è il WWW Il World Wide Web è un sistema per la presentazione a schermo di documenti multimediali, e per l’utilizzo di link ipertestuali per la navigazione. Il sistema è distribuito e scalato su tutta Internet, ed è basato su alcuni semplici concetti: u Il client o browser è un visualizzatore di documenti ipertestuali e multimediali. Può visualizzare testi, immagini e semplici interfacce grafiche, ma non permette di editare documenti. u Il server è un semplice meccanismo di accesso a risorse locali (file o record di database, ecc.) in grado di trasmettere via socket TCP documenti individuati da un identificatore univoco u Il server può collegarsi ad applicazioni server-side (tramite protocollo CGI) ed agire da tramite tra il browser e l’applicazione facendo del browser l’interfaccia dell’applicazione.

5 WWW Fabio Vitali5 I protocolli del WWW Alla base di WWW ci sono i seguenti protocolli: u Uno standard per identificare in maniera generale risorse di rete e per poterle specificare all’interno di documenti ipertestuali (chiamato URI). u Un protocollo di comunicazione state-less e client- server per l’accesso a documenti ipertestuali via rete (chiamato HTTP). u Un linguaggio per la realizzazione di documenti ipertestuali (chiamato HTML) basato su SGML e incentrato sulla possibilità di realizzare connessioni ipertestuali in linea nella descrizione strutturale del documento.

6 WWW Fabio Vitali6 Evoluzioni del WWW (1) n Inclusione di oggetti: Mosaic introdusse il supporto per immagini in- line, e Netscape introdusse poi i plug-in per inserire oggetti di tipi diversi nel documento del browser, ed infine le applet Java. IE ha generalizzato le possibilità offerte da COM, realizzando il protocollo proprietario ActiveX. n Scripting: Netscape introdusse LiveScript, poi ribattezzato Javascript, per realizzare semplici applicazioni client-side con linguaggi di scripting appositi. IE rispose con Jscript e Vbscript. n Stili: L’uso di trucchi per forzare HTML a rese grafiche insolite ha portato a creare linguaggi appositi per gestire gli aspetti di visualizzazione del documento. CSS (livelli 1 e 2) permette di controllare le caratteristiche dei documenti HTML. XSL si occupa di documenti XML.

7 WWW Fabio Vitali7 Evoluzioni del WWW (2) n Gestione delle transazioni: meccanismi per la gestione dello stato sono stati introdotti prima da Netscape, e poi standardizzati (cookies). Meccanismi di accesso in scrittura e cooperazione a risorse WWW vengono studiati in questo periodo (WebDAV). n Strutturazione dei documenti: i limiti di HTML non erano soltanto nella visualizzazione, ma anche nella strutturazione. XML permette di definire linguaggi di markup più adatti ai singoli task. n Modello di link: il modello di link di HTML è eccessivamente semplice. Xlink ed XPointer permettono di definire link sofisticati, sia per indirizzamento (blocchi di dimensione e locazione arbitraria), sia per funzionamento (inclusione in-line, memorizzazione esterna, multi- direzione, ecc.) n Modello di metainformazioni: HTML permette di usare dei tag speciali ma limitati per fornire meta-informazioni sui documenti. RDF estende e generalizza questa possibilità.

8 WWW Fabio Vitali8 URI n Gli URI (Universal Resource Identifier) sono una sintassi usata in WWW per definire i nomi e gli indirizzi di oggetti (risorse) su Internet. n Questi oggetti sono considerati accessibili tramite l’utilizzo di protocolli esistenti, inventati appositamente, o ancora da inventare. n Gli URI si indirizzano a risolvere il problema di creare un meccanismo ed una sintassi di accesso unificata alle risorse di dati disponibili via rete. n Tutte le istruzioni d’accesso ai vari specifici oggetti disponibili secondo un dato protocollo sono codificate come una stringa di indirizzo

9 WWW Fabio Vitali9 L’esigenza di identificatori (1) Gli URI sono stati verosimilmente il fattore determinante per il successo del WWW. Attraverso gli URI, il WWW è stato in grado di identificare risorse accessibili tramite il proprio protocollo, HTTP, e tramite tutti gli altri protocolli esisenti (FTP, Telnet, Gopher, WAIS, ecc.). Il punto principale a cui gli altri sistemi non erano arrivati era una sintassi universale, indipendente dal protocollo e facilmente memorizzabile o scambiabile con cui identificare le risorse di rete.

10 WWW Fabio Vitali10 L’esigenza di identificatori (2) Il WWW utilizza gli identificatori in una varietà di modi: u Link ipertestuali disponibili nel documenti HTML u Immagini ed altri oggetti inclusi nel documento HTML (che è un formato solo testo) u Connessioni e relazioni globali tra documenti (ad esempio, script e link possono essere messi esternamente al documento HTML e da sso riferiti globalmente. In tutti questi casi lo stesso identificatore può essere usato dal protocollo di comunicazione, espresso nella sintassi HTML, o digitato direttamente dall’utente.

11 WWW Fabio Vitali11 Criteri di design degli URI (1) La sintassi degli URI é progettata per essere u Estensibile: si possono aggiungere nuovi schemi, al fine di mantenere l’accessibilità delle risorse anche se nuovi protocolli vengono inventati u Completa: tutti i nomi esistenti sono codificabili e nuovi protocolli sono comunque esprimibili tramite URI u Stampabile: é possibile esprimere URI con caratteri ASCII a 7-bit, così da permettere scambi lungo qualunque canale, per quanto limitato o inefficiente, inclusi carta e penna. Lo standard URI definisce alcune regole per la generazione di schemi di naming (insiemi di nomi caratterizzati dalla dipendenza da un protocollo di accesso comune), per la definizione dei caratteri accettabili e del carattere di escape.

12 WWW Fabio Vitali12 Criteri di design degli URI (2) Gli Universal Resource Identifier (URI) sono, per definizione, o degli Universal Resource Names (URN), o degli Universal Resource Locator (URL). u Gli URL sono un indirizzo della risorsa che possa essere immediatamente utilizzato da un programma per accedere alla risorsa. u Gli URL contengono tutte le informazioni necessarie per accedere all’informazione, ma sono fragili a modifiche non sostanziali del meccanismo di accesso (es. cambio del nome di una directory). u Gli URN sono un nome stabile e definitivo di una risorsa, che possa fornire un informazione certa ed affidabile sulla sua esistenza ed accessibilità. u Gli URN debbono essere trasformati da un apposito servizio, negli URL attualmente associati alla risorsa. Inoltre la mappa deve essere aggiornata ogni volta che la risorsa viene spostata.

13 WWW Fabio Vitali13 URL Lo schema, in un URL, corrisponde al protocollo di accesso da usare per accedere alla risorsa. La parte specifica dipende dal protocollo specifico. u HTTP e HTTPS - La sintassi è: http://host[:port]/path[#fragment][?query] https://host[:port]/path[#fragment][?query] F host é l’indirizzo TCP-IP o DNS, dell’host su cui si trova la risorsa F port é la porta a cui il server é in ascolto per le connessioni. In mancanza di specificazione, la porta é quella di default, 80 per HTTP e 443 per HTTPS. F path é un pathname gerarchico per l’identificazione della risorsa F fragment é un identificativo di una sottoparte dell’oggetto. La definizione e il ritrovamento di queste sottoparti é a carico del client, e quindi la parte di fragment viene ignorata dal server, che restituisce l’intero oggetto. F query é una frase che costituisce l’oggetto di una ricerca sulla risorsa specificata. u FTP - La sintassi è: ftp://[user[:password]@]host[:port]/path [type] F User e password sono utente e password per l’accesso ad un server FTP. La loro mancanza fa partire automaticamente una connessione anonima F Host, port e path sono l’indirizzo del server, la porta di connessione ed il nome del file dell’oggetto ricercato, come per HTTP. La porta di default è 21. F type regola i parametri di connessione FTP, come il tipo di trasferimento

14 WWW Fabio Vitali14 HTTP HTTP (HyperText Transfer Protocol) Un protocollo stateless per la ricerca, il recupero e la manipolazione n HTTP é un protocollo con la leggerezza e la velocità necessari per un sistema informativo ipertestuale distribuito e collaborativo. n E’ un protocollo generico, stateless, object-oriented, che può essere usato anche per scopi diversi dallo scambio di documenti ipertestuali, come name server, per sistemi object-oriented distribuiti, ecc. n Caratteristica importante in HTTP é la negoziazione del formato di dati utilizzato, per garantire l’indipendenza del sistema dal formato di rappresentazione dei dati. n HTTP è esistito in tre versioni: 0.9, 1.0 (RFC 1945) e 1.1 (RFC 2616) n Netscape ha proposto il meccanismo dei cookie nel’RFC 2109.

15 WWW Fabio Vitali15 Ruoli delle applicazioni HTTP (1) HTTP è un protocollo di comunicazione piuttosto semplice, basato sulla comunicazione tra due applicazioni, il browser, che manda richieste di documenti, ed il server, che risponde. In realtà i ruoli sono un po’ più precisi: u Client: un’applicazione che stabilisce una connessione HTTP, con lo scopo di mandare richieste. u Server: un’applicazione che accetta connessioni HTTP, e genera risposte. u User agent: Quel particolare client che inizia una richiesta HTTP (tipicamente un browser, ma può anche essere un bot). u Origin server: il server che possiede fisicamente la risorsa richiesta (è l’ultimo della catena)

16 WWW Fabio Vitali16 Ruoli delle applicazioni HTTP (2) u Proxy: Un’applicazione intermediaria che agisce sia da client che da server. Le richieste sono soddisfatte autonomamente, o passandole ad altri server, con possibile trasformazione, controllo, verifica. u Gateway: un’applicazione che agisce da intermediario per qualche altro server. A differenza del proxy, il gateway riceve le richieste come fosse l’origin server: il client può non essere al corrente che si tratta del gateway. u Tunnel: un programma intermediario che agisce da trasmettitore passivo di una richiesta HTTP. Il tunnel non fa parte della comunicazione HTTP, anche se può essere stato attivato da una connessione HTTP. In più è importante ricordare: u Cache: memoria locale di un'applicazione e il sistema che controlla i meccanismi della sua gestione ed aggiornamento. Qualunque client o server può utilizzare una cache, ma non un tunnel.

17 WWW Fabio Vitali17 La connessione HTTP (1) n La connessione HTTP è composta da una serie di richieste ed una serie corrispondente di risposte. n La differenza principale tra HTTP 1.0 e 1.1 è stata la possibilità di specificare coppie multiple di richiesta e risposta nella stessa connessione. n Le richieste possono essere messe in pipeline, ma le risposte debbono essere date nello stesso ordine delle richieste, poiché non è specificato un metodo esplicito di associazione.

18 WWW Fabio Vitali18 La connessione HTTP (2) clientserver HTTP 1.0 open close open close open close clientserver HTTP 1.1 open close clientserver HTTP 1.1 con pipelining open close

19 WWW Fabio Vitali19 La richiesta dove  Method indica l’azione del server richiesta dal client  URI è un identificativo di risorsa locale al server  Version è “HTTP/1.0” o “HTTP/1.1”  Header sono linee RFC822, classificabili come header generali, header di entità, ed header di richiesta.  Body è un messaggio MIME Method URI Version CrLf [Header]* CrLf Body La richiesta è un messaggio formato da una riga di richiesta e da dati ulteriori facoltativi.

20 WWW Fabio Vitali20 Un esempio di richiesta GET /beta.html HTTP/1.1 Referer: http://www.alpha.com/alpha.html Connection: Keep-Alive User-Agent: Mozilla/4.61 (Macintosh; I; PPC) Host: www.alpha.com:80 Accept: image/gif, image/jpeg, image/png, */* Accept-Encoding: gzip Accept-Language: en Accept-Charset: iso-8859-1,*,utf-8

21 WWW Fabio Vitali21 I metodi della richiesta (1) GET u Il più importante metodo di HTTP, richiede una risorsa ad un server. u Questo è il metodo più frequente, ed è quello che viene attivato facendo click su un link ipertestuale di un documento HTML, o specificando un URL nell’apposito campo di un browser. HEAD u Il metodo HEAD è simile al metodo GET, ma il server deve rispondere soltanto con gli header relativi, senza il corpo. u HEAD viene usato per verificare: F la validità di un URI: la risorsa esiste e non è di lunghezza zero, F l’accessibilità di un URI: la risorsa è accessibile presso il server, e sono on sono richieste procedure di autenticazione del documento. F la coerenza di cache di un URI: la risorsa non è stata modificata nel frattempo, non ha cambiato lunghezza, valore hash o data di modifica.

22 WWW Fabio Vitali22 I metodi della richiesta (2) POST u Il metodo POST serve per trasmettere delle informazioni dal client al server, ma senza la creazione di una nuova risorsa. u POST viene usato per esempio per sottomettere i dati di una form HTML ad un’applicazione CGI sul server. PUT u Il metodo PUT serve per trasmettere delle informazioni dal client al server, creando o sostituendo la risorsa specificata. u In generale, l’argomento del metodo PUT è la risorsa che ci si aspetta di ottenere facendo un GET in seguito con lo stesso nome. L’argomento del metodo POST, invece, è una risorsa esistente a cui si aggiunge (es. come input) informazione.

23 WWW Fabio Vitali23 Gli header Gli header sono righe (nome: valore) che specificano caratteristiche del messaggio trasmesso o ricevuto: esse si dividono in: u Header generali della trasmissione Data, codifica, versione, tipo di comunicazione, ecc. u Header dell’entità trasmessa Content-type, Content-Length, data di scadenza, ecc. u Header della richiesta effettuata Chi fa la richiesta, a chi viene fatta la richiesta, che tipo di caratteristiche il client è in grado di accettare, che autorizzazione puo’ portare, ecc. u Header della risposta generata Che server dà la risposta, che tipo di autorizzazione è necessaria, ecc.

24 WWW Fabio Vitali24 La risposta Version status-code reason-phrase CrLf [Header]* CrLf Body GET /index.html HTTP/1.1 Host: www.cs.unibo.it:80 HTTP/1.1 200 OK Date: Fri, 26 Nov 1999 11:46:53 GMT Server: Apache/1.3.3 (Unix) Last-Modified: Mon, 12 Jul 1999 12:55:37 GMT Accept-Ranges: bytes Content-Length: 3357 Content-Type: text/html ….

25 WWW Fabio Vitali25 Status code Lo status code è un numero di tre cifre, di cui la prima indica la classe della risposta, e le altre due la risposta specifica. Esistono le seguenti classi: u 1xx: Informational. Una risposta temporanea alla richiesta, durante il suo svolgimento. u 2xx: Successful. Il server ha ricevuto, capito e accettato la richiesta. u 3xx: Redirection. Il server ha ricevuto e capito la richiesta, ma sono necessarie altre azioni da parte del client per portare a termine la richiesta. u 4xx: Client error. La richiesta del client non può essere soddisfatta per un errore da parte del client (errore sintattico o richiesta non autorizzata). u 5xx: Server error. La richiesta può anche essere corretta, ma il server non è in grado di soddisfare la richiesta per un problema interno (suo o di applicazioni CGI).

26 WWW Fabio Vitali26 Esempi di status code 100Continue (se il client non ha ancora mandato il body) 200Ok (GET con successo) 201Created (PUT con successo) 301Moved permanently (URL non valida, il server conosce la nuova posizione 400Bad request (errore sintattico nella richiesta) 401Unauthorized (manca l’autorizzazione) 403Forbidden (richiesta non autorizzabile) 404Not found (URL errato) 500Internal server error (tipicamente un CGI mal fatto) 501Not implemented (metodo non conosciuto dal server)

27 WWW Fabio Vitali27 I cookies HTTP è stateless: non esiste nessuna struttura ulteriore alla connessione, e il server non è tenuto a mantenere informazioni su connessioni precedenti. Un cookie (non è in HTTP, è un’estensione di Netscape, proposta nell’RFC 2109) è una breve informazione scambiata tra il server ed il client. Il client mantiene lo stato di precedenti connessioni, e lo manda al server di pertinenza ogni volta che richiede un documento. Questioni di sicurezza permettono di distinguere tra cookies spediti solo al server di appartenenza e cookies spediti a qualunque computer del dominio.

28 WWW Fabio Vitali28 I cookies (2) client server HTTP applicazione CGI request Output + cookie Risposta + Set-Cookie request + Cookie Output Risposta genera il cookie analizza il cookie

29 WWW Fabio Vitali29 Bibliografia E. Wilde, Wilde’s WWW, Springer Verlag, 1999 Altri testi (gli RFC sono disponibili come http://www.ietf.org/rfc/rfc####.txt ) u K. Sollins, L. Masinter, Functional Requirements for Uniform Resource Names, RFC 2276, Jan. 1998, u T. Berners-Lee, L. Masinter, M. McCahill, Uniform Resource Locator, RFC 1738, Dec. 1994 u R. Fielding, Relative Uniform Resource Locator, RFC 1808, Jun 1995. u T. Berners-Lee, R. Fielding, H. Frystyk, Hypertext Transfer Protocol -- HTTP/1.0, RFC 1945, May 1996 u D. Kristol, L. Montulli, HTTP State Management Mechanism, RFC 2109, February 1997 u R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners- Lee, Hypertext Transfer Protocol -- HTTP/1.1, RFC 2616, June 1999 u D. Raggett, A. Le Hors, I. Jacobs, HTML 4.01 Specification, W3C Recommendation 24 December 1999, http://www.w3.org/TR/html401