Alma Mater Studiorum - Universita' di Bologna
Sede di Cesena
II Facolta' di Ingegneria
Reti di Calcolatori
World Wide Web e HTTP
Vedi:
• A.S. Tanenbaum, Computer Networks, 4th ed., Prentice Hall,
sez. 7.3, pagg. 611-662.
• D. Comer, Internetworking con TCP/IP - Principi, protocolli e
architetture, vol. 1, Addison-Wesley, cap. 28, pagg. 527-537.
Copyright © 2006-2011 by Claudio Salati.
Lez. 12
1
Il 18 brumaio di Luigi Bonaparte
(incipit)
“Hegel nota in un passo delle sue opere che tutti i grandi
fatti e i grandi personaggi della storia universale si
presentano, per cosí dire, due volte.
Ha dimenticato di aggiungere:
la prima volta come tragedia, la seconda volta come farsa.”
Karl Marx
Il 18 brumaio (9 novembre) 1799, Napoleone Bonaparte abbatté con un colpo di stato il
regime dei Direttorio ed instaurò in Francia la sua tirannide personale, da cui doveva
nascere, qualche anno dopo, l’Impero.
Il 2 dicembre 1851, Luigi Napoleone ripeté il gesto dello zio, distruggendo la repubblica del
1848 come questi aveva distrutto la repubblica del 1793.
2
Come nasce il WWW (World Wide Web)
• Una infrastruttura client-server
• distribuita su Internet
• in cui documenti (pagine, in gergo Web)
• (potenzialmente) ipertestuali
• (potenzialmente) multimediali
• normalmente basati sull'utilizzo di linguaggi di mark-up
(e.g. HTML, XML, XUL)
• residenti sui server (Web-server)
• possono essere riferiti (e indirizzati!) e possono riferirirsi tra loro
• tramite URL (Uniform Resource Locators)
• e possono essere acceduti (letti, scritti, modificati, ...) da
applicazioni residenti sui client (e.g. un Web-browser)
• tramite le operazioni messe a disposizione dal protocollo HTTP
(HyperText Transfer Protocol)
3
Documenti strutturati
• L'accesso in lettura ad un documento da parte del client e' di norma
collegato al suo rendering sulla user interface
• In particolare, al suo display sullo schermo di un Web-browser
• Ma anche alla sua stampa su hard-copy
Da cio’:
• Necessita’ di poter descrivere la struttura logica del documento
• Necessita’ di poter descrivere le caratteristiche di
rappresentazione grafica dei contenuti del documento
• Documenti ipertestuali:
• link all’interno di un documento
• link tra documenti tramite URL
• link a file multimediali
Da cio’:
• Necessita’ di poter inserire in un documento riferimenti
riconoscibili come tali
4
Documenti strutturati
• Documenti multimediali:
• basati sull’utilizzo di link ipertestuali tra documenti
• testi, immagini, sonori, ...
• in diversi formati (e.g. JPEG vs. GIF vs. PNG vs. TIF vs. BMP ...)
Da cio’:
• Necessita’ di poter inserire in un documento riferimenti a
sottodocumenti che
• devono essere considerati parte del e
• devono essere incorporati nel
documento che li riferisce.
• Necessita’ che questi riferimenti siano tipizzati per operare
l’inserimento in modo corretto.
5
Documenti tipizzati
• Il client deve processare:
• Documenti e sotto-documenti di diverso tipo;
• Documenti che, pur essendo di uno stesso tipo, codificano
l’informazione in modo diverso.
• Da cio’ la necessita' di:
• Comunicare esplicitamente il tipo di un documento ed il suo
formato (comunicazioni serverbrowser).
• Avere sul client processori capaci di gestire il tipo/formato dei
documenti ricevuti dal server.
 Un Web-browser non puo’ esere capace di processare tutti i
tipi di documenti in tutti i formati possibili, per sempre.
 Il Web-browser deve essere espandibile/aperto in modo da
poter interagire con processori di documenti esterni.
 Ma non e’ comunque garantito che una piattaforma browser
sia capace di supportare tutti i tipi di informazione gestiti 6
da un server.
Interazione client-server
• Nelle sue interazioni con il server il client deve poter specificare le
sue capacita’ / opzioni preferite
• Tipo di browser e sistema operativo
• Diversi sistemi operativi hanno/non hanno convenzioni
specifiche per mappare un nome di file nel tipo di
informazion che esso contiene.
• Set di caratteri
•
Codifiche supportate per un certo tipo di informazioni
(e.g. JPEG e' meglio di GIF).
 Nell’ipotesi che il server sia capace di adeguare il suo
comportamento alle opzioni preferite dal client.
• Esempio: il sito http://dm.unife.it/~salati/ funziona bene con
Chrome ma non con Explorer
7
Linguaggi di mark-up: HTML
• utilizzati nel type-setting, simili logicamnete a nroff, troff, TEX
• capaci di rispondere all’esigenza di creare documenti strutturati
• Mediante l’uso di tag:
<tag> . . .
</tag>
• Ogni tag ha associata una semantica predefinita
• in HTML (come in nroff, troff, TEX) ambiguita' tra
• strutturazione logica del documento (scopo fondamentale)
• head vs. body
• titolo di n-esimo livello
• indicazioni di grafica (e.g. boldface)
• N.B.: comunque, il responsabile ultimo del rendering di un documento
HTML e’ il Web-browser ( possibili pagine differenziate per browser).
• necessita’ di separate le regole di composizione/rappresentazione di
un documento e il suo contenuto
• per uniformare lo stile delle pagine di un sito Web
• utilizzo di style-sheet riferiti dalle pagine tramite link ipertestuali 8
Linguaggi di mark-up: HTML
• in ogni caso, non si da' nessuna strutturazione all'informazione
contenuta nel documento
• esempio:
• un negozio di libri e' costituito da una lista di libri,
• e ogni libro e' costituito del titolo, dell'autore, della casa editrice,
dell'anno di pubblicazione, del prezzo, …
• e il titolo e' una stringa di caratteri,
• mentre il prezzo e' un numero reale espresso in euro,
• …
9
HTML: esempio
(a) Testo sorgente HTML
(b) Rendering del testo
HTML sullo schermo
del browser
10
Tag HTML
11
Esempi di hyperlink
• All’interno di un documento (puntatore):
<a href="#Teoria"> Lezioni </a>
. . .
<a name="Teoria"> Lezioni </a>
• Tra due documenti all’interno dello stesso sito (relativo)(puntatore):
<a href="pubblicazioni.htm"> Pubblicazioni </a>
• Tra due documenti anche non all’interno dello stesso sito (puntatore):
<a
href=“http://dm.unife.it/~salati/pubblicazioni.htm">
Pubblicazioni </a>
• Inclusione (dell’oggetto puntato) di un’immagine nella pagina:
<img width=15 height=14 src="./BlueDot.gif">
12
Linguaggi di mark-up: XML
• XML separa l'aspetto della strutturazione logica del documento e del
suo contenuto da quello del suo rendering sullo schermo del browser
• strutturazione logica del testo
• ma anche strutturazione dell'informazione contenuta nel testo
• I tag XML di per se’ stessi non hanno alcuna semantica associata
• Possiamo pero' definire dei meta-testi XML
• in cui i tag hanno una semantica associata,
• e che descrivono la semantica che vogliamo assegnare ai tag di
altri testi XML
• e i meta testi stessi possono essere scritti in XML
• Esempio di meta-testo: style-sheet
• descritti in XSL (linguaggio XML-based)
• consentono di descrivere le regole di rendering logico di pagine
scritte in XML
13
XML: strutturazione dell’informazione
• Basata sull’uso di un meta-testo XML: XML Schema
• XML Schema
• linguaggio XML-based
• consente di descrivere (come XDR) la struttura dell'informazione
(tipizzata, sintassi astratta) contenuta in pagine XML
(corrispondenti a sintassi di trasferimento)
• informazione tipizzata “come in XDR”
• Insieme di tipi base
• Insieme di costruttori di tipi derivati
• XML Schema definisce
• sia una notazione per la definizione di sintassi astratte (per la
definizione di tipi di dato), basata su XML
• sia una sintassi di trasferimento (per la rappresentazione concreta
di valori tipizzati di una sintassi astratta, riferita con un iperlink nel
testo della sintassi di trasferimento), anch’essa basata su XML 14
Esempio di schema: Bookshop_schema.xsd
<xsd:schema
xmlns:xsd="http:www.w3c.org/2001/XMLSchema“
elementFormDefault="qualified" >
<xsd:element name="BookStore">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="Book" type="BookType"
maxOccurs="unbounded“ />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:complexType name="BookType">
<xsd:sequence>
<xsd:element name="Title" type="xsd:string" />
<xsd:element name="Author" type="xsd:string" />
<xsd:element name="Puslisher" type="xsd:string" />
<xsd:element name="Puslished" type="xsd:gYear" />
<xsd:element name="PriceEuro" type="xsd:float" />
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
15
Esempio di valore tipizzato
<?xml version="1.0"?>
<BookStore
xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="./Bookshop_schema.xsd">
<Book>
<Title>Computer Networks, 4th Edition</Title>
<Author>Andrew S. Tanenbaum</Author>
<Puslisher>Pearson Education International</Puslisher>
<Puslished>2003<Puslished>
<PriceEuro>89.95<PriceEuro>
</Book>
<Book>
<Title>Interneworking with TCP/IP</Title>
<Author>Dougles E. Comer</Author>
<Puslisher>Pearson - Prentice Hall</Puslisher>
<Puslished>2006<Puslished>
<PriceEuro>87.94<PriceEuro>
</Book>
. . .
</BookStore>
16
Catena dei significati
.1
• XML Schema definisce il significato delle parole utilizzate per scrivere
lo schema Bookshop_schema.xsd.
• XML Schema definisce il significato di tutti i simboli primitivi del
linguaggio.
• Nel testo questi simboli compaiono prefissati con la stringa “xsd:”.
• Bookshop_schema.xsd riferisce nella sua intestazione
XMLSchema, il metatesto che assegna un significato alle parole
contenute nel proprio testo.
• XML Schema consente di assegnare un significato ai simboli definiti
dall’utente in Bookshop_schema.xsd.
• Consente di definire Book come nome di un element di tipo
BookType
• Consente di definire come e’ fatto un valore di tipo BookType
• Bookshop_schema.xsd rappresenta la definizione di una sintassi
astratta.
17
Catena dei significati
.2
• Lo schema Bookshop_schema.xsd definisce quale e’ la struttura
di un valore di tipo BookStore.
• Lo schema Bookshop_schema.xsd definisce il significato dei tag
BookStore, Book, Title, …
• Lo schema Bookshop_schema.xsd definisce quale tipo di valore
puo’ essere assegnato a un elemento identificato da uno di questi
tag.
• Il valore BookStore riferisce il meta-testo XML
Bookshop_schema.xsd che definisce il significato dei suoi tag e
dei suoi attributi.
• Il valore BookStore riferisce anche il meta-testo XML XMLSchemainstance che lo definisce essere un valore (una sintassi di
trasferimento) di uno schema definito in XML Schema.
• Il valore BookStore rappresenta una istanza di sintassi di
trasferimento.
18
Linguaggi di mark-up: strumenti
• Processore XSLT per tradurre dal testo originario (e.g. XML) ad un
altro testo target (e.g. HTML)
• Consente, a partire da un unico testo sorgente, eventualmente
servendosi di opportuni style-sheet di produrre diversi testi target
adatti al rendering su diversi media
• Parser XML
• Parser XML/XML Schema
• Verifica anche che un testo XML sia consistente con il testo XML
Schema che ne descrive sintassi e semantica
• Interpreti HTML e XSLT (e XML) disponibili su tutti i browser (XSLT
anche sui server)
19
Evoluzione dell'interazione client-server
.1
• Trasferimento serverclient di pagine con contenuto dinamico e
non di documenti statici
• e.g. orario dei treni da A a B, tra le ore X e Y del giorno Z
• strumenti sul server per costruire pagine XML/HTML con
contenuto dinamico (su template fisso):
• JSP
• PHP
• Servlet (procedura Java)
• Sul server un URL puo’ riferire non una pagina passiva ma una
procedura JSP/PHP/Java
• Trasferimento di informazioni clientserver tramite una pagina
(form), e.g.
• carta di credito
• informazioni A, B, X, Y, Z dell’esempio precedente
20
Evoluzione dell'interazione client-server
.1’
• Quindi il client non e’ solo un visualizzatore di pagine passive
ricevute dal server!
• Pagine attive lato client
• Applet Java
• Javascript
• XUL
Attive perche’ possono interagire attivamente con il server:
• Per aggiornare i dati visualizzati sulla pagina
• Per fornire dati al server
• Per richiedere (con parametri) una nuova pagina al server
• Interazioni client-server con stato (sessioni)
• e.g. shopping cart
• Realizzate a livello di applicazione finale: cookie di sessione
scambiato tra client e server in ogni interazione della stessa
sessione
21
Evoluzione dell'interazione client-server
.2
• Ma una servlet e’ una procedura Java.
• Chi dice che deve ritornare al client un intero documento da
visualizzare?
• Potrebbe ritornare anche solo dei dati strutturati (e.g. in un testo
XML), cosi’ che il client (una procedura Java o Javascript in
esecuzione sul browser) li possa inserire nella pagina
visualizzata.
• Ma perche’ poi dovrebbe limitarsi a restituire qualcosa al client
piuttosto che fare anche qualcosa sulla macchina server?
• Una servlet non e’ nient’altro che una RPC chiamata da un Webclient.
• E i parametri di ingresso?
• Staranno anche loro da qualche parte nel PDU HTTP che ha
attivato la servlet!
• Per i parametri di ritorno non c’e’ evidentemente problema!
22
Evoluzione dell'interazione client-server
.3
• Ma poi, chi dice che il client sia necessariamente solo un browservisualizzatore di pagine HTML?
• Se il browser e’ un interprete di codice Java/Javascript, ed e’ questo
codice che gestisce l’interazione HTTP, il contenuto dei PDU HTTP
scambiati e’ definito da questo codice.
• Il codice Java/Javascript in esecuzione sul client puo’ aspettarsi di
vedersi ritornare dal server dei dati strutturati (e.g. in un testo XML)
anziche’ una intera pagina HTML.
 E.g. per utilizzarli per aggiornare dei dati visualizzati nella pagina
corrente.
 In questo modo posso realizzare delle pagine aggiornate on-line.
• Ma poi chi lo dice che il client debba essere necessariamente un
browser piuttosto che un qualunque programma che utilizza una
protocol entity HTTP client per interagire con un Web-server (e con
delle servlet installate su di lui)!
 E a questo punto e’ il programma client che decide cosa fare dei
dati ricevuti dal server.
 E che concorda con la servlet quale e’ il protocollo che regola 23
la loro interazione.
URL
• In realta' fin dall'origine gli URL sono stati definiti per potere supportare
diversi protocolli applicativi oltre che HTTP, e.g.
• protocollo ftp per l'accesso a file remoti
• protocollo file per l'accesso a file locali al client
• protocollo SMTP (acronino URL: mailto) per accesso al mailing
system Internet
• Il formato di un URL dipende quindi dal protocollo che si vuole utilizzare
per accedere alla risorsa.
• nel caso del mailing system l'URL ha formato:
mailto:<user-name>@<DNS-domain-name>
• nel caso dell'accesso al file system locale l'URL ha formato:
file:///<file's-path-name>
• nel caso dell'accesso file remoti l'URL ha formato :
ftp://<DNS-domain-name>/<file's-path-name>
24
URL HTTP
• http://
<DNS-domain-name>[:<port>]/
<resource's-path-name>
[;<parameters>]
[?<query>]
• <DNS-domain-name> puo' essere sostituito dall'indirizzo IP del server
su cui risiede la risorsa.
• La porta default utilizzata dal protocollo HTTP e' la numero 80.
• <resource's-path-name> puo' essere ad esempio il path-name (a partire
da un qualche directory dedicato del file system della macchina server)
del file che contiene il documento che si vuole accedere
• <parameters> rappresenta un insieme di parametri opzionali aggiuntivi
che possono essere forniti al server per dirigere il processamento della
risorsa una volta che questa e' stata identificata
• <query> rappresenta anch'esso un insieme di parametri opzionali
aggiuntivi che possono essere forniti al server per dirigere il
processamento della risorsa (in una operazione di GET).
25
URL HTTP: esempio
.1
http://dm.unife.it/~salati
• Il Web-server che vogliamo riferire risiede sullo host dm.unife.it
• Esso accede alla rete via HTTP utilizzando la porta numero 80.
• Il path-name ~salati identifica per convenzione
• il file index.html
• che si trova nel sottodirectory public_html
• nella home-directory dell'utente salati
• Non ci sono parametri aggiuntivi.
• L'esempio mostra che le regole di localizzazione della risorsa a partire
dal <resource's-path-name> possono essere piuttosto complesse.
• Lo hyperlink (relativo)
<a href="pubblicazioni.htm">Pubblicazioni</a>
contenuto nella pagina index.html porta a generare un PDU HTTP
contenente l’URL
http://dm.unife.it/~salati/pubblicazioni.htm
26
URL HTTP: esempio
.2
http://orario.trenitalia.com/b2c/nppPriceTravelSolutio
ns.do?car=0&stazin=Bologna&stazout=Cesena&datag=28&dat
am=09&dataa=2010&timsh=7&stazin_r=Staz_DA&stazout_r=St
az_A&timsm=58&timsm_r=58&lang=it&nreq=5&channel=tcom&n
pag=1&lang_r=it&nreq_r=5&channel_r=tcom&npag_r=1&x=27&
y=10
• Il Web-server che vogliamo riferire risiede sullo host
orario.trenitalia.com
• Esso accede alla rete via HTTP utilizzando la porta numero 80
• Il resource path-name e’ b2c/nppPriceTravelSolutions.do
• L’URL comprende il parametro <query>
car=0&stazin=Bologna&stazout=Cesena&datag=28&datam=09&dat
aa=2010&timsh=7&stazin_r=Staz_DA&stazout_r=Staz_A&timsm=5
8&timsm_r=58&lang=it& . . .
• N.B.: il valore del parametro <query> non e’ indicato tramite caratteri
normali ma e’ URL-encoded!
27
Protocollo HTTP
.1
• La versione 1.1 e' definita in RFC 2616.
• E' un protocollo richiesta/risposta:
• interazioni confermate.
• interazioni “bloccanti”:
• il client invia una richiesta, poi non puo’ inviare nessun’altra
richiesta sulla stessa connessione fino a che non ha ricevuto la
risposta alla richiesta precedente.
• in realta’ non e’ proprio cosi’: dipende dall’API che utilizza.
Ma comunque e’ il server che dopo avere preso in carico una
richiesta da una connessione TCP non ne prende piu’ in carico
nessun’altra dalla stessa connessione fino a che non ha
terminato di processare la prima.
• E' un protocollo stateless:
• ogni operazione e' processata per conto proprio.
• non esiste una nozione di connessione o sessione HTTP:
se si vuole realizzarla bisogna farlo a livello di applicazione.
28
Protocollo HTTP
.2
• Il server attende le richieste del client: quando ne riceve una, la
processa e invia al client la corrispondente risposta.
• I server HTTP:
• Sono normalmente implementati come servizi concorrenti (multithreading), ma su una singola connessione gestiscono una sola
operazione per volta.
• Sulla singola connessione hanno un comportamento sequenziale,
congruentemente con il fatto che una interazione client-server e’
“bloccante” per il client.
• Il protocollo HTTP consente a client e server di negoziare le modalita' di
colloquio (e.g. la lingua) e scambiare informazioni sulla propria identita'
e sulle proprie potenzialita‘ (e.g. capacita’ di visualizzare immagini
PNG).
N.B.: come si fa se HTTP e' stateless? Cookie!
• I PDU HTTP sono character-oriented e il loro formato e' largamente
derivato da quello dei PDU del protocollo SMTP (mail).
29
Protocollo HTTP: problemi
• Se si vuole consentire al Web-server di aggiornare dinamicamente una
pagina sul Web-browser c’e’ bisogno di tenere impostata in permanenza
una richiesta del browser verso il server per consentire a questi di
inviargli informazioni.
 Il server puo’inviare dati al client solo come risposta a una richiesta
fatta da questo.
 N.B.: normalmente l’aggiornamento della pagina avviene tramite un
suo ricaricamento da parte del browser (la pagine HTML posso
essere marcate come “da ricaricare”): vedi www.ansa.it.
 Il ricaricamento dell’intera pagina HTML e’ inutilmente dispendioso
perche’ normalmente la parte di pagina da aggiornare e’ molto piu’
piccola della pagina nel suo complesso!
• Se si vuole consentire contemporaneamente al server di aggiornare
dinamicamente una pagina sul browser e al browser di effettuare una
nuova richiesta e’ necessario aprire due connessioni TCP tra browser e
server!
• In generale: se da un browser voglio eseguire contemporaneamente
diverse operazioni su un server, ho bisogno di aprire piu’ connessioni
30
TCP, una per ogni richiesta concorrente.
HTTP transport mapping
.1
• HTTP utilizza il Servizio di Trasporto Connection-Oriented (TCP)
• quindi non deve preoccuparsi di trattare errori di comunicazione
• ma deve preoccuparsi di segmentare un PDU in una sequenza di
write(), e assicurarsi che tutti i byte siano trasmessi
• La porta well-known del servizio www e’ la 80
• HTTP puo' anche fare uso della versione "sicura" del Servizio di
Trasporto Connection-Oriented (SSL/TLS, a sua volta basato
sull'utilizzo di TCP).
• si parla di HTTPS, che utilizza per default la porta TCP 443
• dal punto di vista formale del modello di riferimento OSI la
funzionalita’ di de/crittazione delle comunicazioni e’ considerata un
servizio del Layer di Presentazione
31
HTTP transport mapping
.2
• Nella versione 1.0 il client HTTP apriva una nuova connessione di
trasporto per ogni operazione che voleva richiedere al server;
• e il server chiudeva la connessione dopo avere inviato la risposta;
• in questo modo il client riusciva anche a capire che il testo della
risposta era terminato!
• Nella versione 1.1 HTTP si basa invece (normalmente) sull'utilizzo di
una connessione persistente tra un client e un server:
• successive richieste viaggiano su una stessa connessione di
trasporto, e la connessione viene chiusa dal client quando questo
non e' piu' interessato ad interagire con il server;
• questa politica e' stata adotta per ragioni di efficienza;
• in realta’ un client puo’ aprire piu’ connessioni verso uno stesso
server.
• problema: come fa il server ad indicare al client che e' terminata
una risposta?
• Ci sono comunque timeout di supervisione del dialogo che
controllano la gestione della connessione.
32
HTTP transport mapping: timeout di supervisione
•
Quando il client invia una richiesta al server attiva un timer:
 se la risposta dal server non e’ ricevuta prima che il timer scada,
la transazione viene abortita.
•
Il server ha attivo in modo permanente un timer di supervisione delle
interazioni con il client su ogni connessione aperta:
 se vede che una connessione rimane inattiva (nessun PDU
HTTP e’ ricevuto su di essa) per un intervallo troppo lungo, la
chiude.
33
Operazioni HTTP
.1
• Ogni operazione HTTP puo’ essere vista come l’invocazione da
parte del Web-browser di una procedura remota sul Web-server.
• L’URL e’ il riferimento alla (l’indirizzo della) risorsa (di solito, una
pagina), allocata sul server, su cui si vuole eseguire l’operazione.
34
Operazioni HTTP
.2
• In realta' non necessariamente un URL riferisce una pagina Web.
• Un URL (in realta’, una coppia [operazione HTTP, URL]) puo' anche
designare un script o un programma eseguibile allocato sul Webserver.
• In questo caso il significato (la semantica) dell'operazione HTTP
e' definito dal codice dello script o del programma.
• Invocare una operazione HTTP su un URL che rappresenta uno
script o un programma eseguibile equivale ad invocare una
procedura remota.
• Un URL puo’ essere visto come un riferimento ad una risorsa
remota (un oggetto remoto) su cui posso eseguire diverse
operazioni.
• Ogni operazione HTTP consente di indicare una diversa
operazione che voglio eseguire sulla risorsa remota.
• Addirittura, si potrebbe utilizzare il PDU HTTP (e.g. quello di POST)
per trasportare un protocollo applicativo stile RPC!
 WebServices o equivalenti!
35
HTTP: PDU di richiesta
linea di richiesta
metodo SP
header field name
header lines
corpo del PDU
: SP
valore
CR LF
valore
CR LF
...
header field name
linea vuota
SP versione CR LF
URL
: SP
CR LF
...
• <versione> attualmente ha il valore HTTP/1.1.
• la specifica del formato del PDU e' particolarmente tediosa perche'
la sintassi di trasferimento e’ text-based.
• il PDU di richiesta e' simile ad un PDU SMTP (RFC 822) con
estensione MIME (Multipurpose Internet Mail Extensions).
• come fa il server a capire che il corpo del PDU, e quindi il PDU
stesso, sono terminati?
36
HTTP: PDU di risposta
linea di stato
versione SP codice di stato SP frase di stato CR LF
header field name
header lines
corpo del PDU
valore
CR LF
valore
CR LF
...
header field name
linea vuota
: SP
: SP
CR LF
...
• <versione> attualmente ha il valore HTTP/1.1.
• <codice di stato> e' una stringa numerica che fornisce l'esito
dell'operazione (per il processamento elettronico).
• <frase di stato> e' una stringa human-oriented per indicare l'esito
dell'operazione.
• la risposta e' simile ad un PDU SMTP (RFC 822) con estensione
MIME (Multipurpose Internet Mail Extensions).
• come fa il client a capire che il corpo del PDU, e quindi il PDU stesso,
37
sono terminati?
HTTP: codice di stato del PDU di risposta
38
Esempi di HTTP message headers
Both
39
Esempi di MIME type
•
•
•
Content-Type: text/html; charset=ISO-8859-4
Content-Type: text/plain; charset=us-ascii
Content-Type: image/gif
40
HTTP e proxy
• Il protocollo HTTP e' fatto per supportare un terzo componente
dell'architettura di rete Web: il proxy.
• L'utilizzo di proxy e' necessario per migliorare l'efficienza del
sistema attraverso il caching gerarchico delle informazioni.
• L'esistenza di proxy intermedi tra client e server e' supportata
esplicitamente dal protocollo HTTP
• attraverso opportuni message header che possono essere
utilizzati da un proxy
• il message header if-modified-since consente di chiedere
al server di trasferire una pagina solo se questa e' stata
modificata di recente
• attraverso la possibilita' per un server di controllare il caching
dell'informazione sui proxy intermedi
• evitando ad esempio il caching di pagine dinamiche
41
Come si evolve (e' evoluto) il WWW
• Una infrastruttura client-server
• distribuita su Internet
• in cui risorse residenti sui server o comunque controllabili tramite
applicazioni residenti sui server
• possono essere riferite (e indirizzate) e possono riferirirsi tra loro
• tramite URL
• e possono accedersi tra loro e essere accedute da applicazioni
residenti sui client
• tramite le operazioni messe a disposizione dalla loro interfaccia
• l'interfaccia client-server puo' essere definita nei termini delle
operazioni fornite dal protocollo HTTP
• l'interfaccia puo' essere definita in altri termini (e.g. WSDL) e
utilizzare HTTP solo come protocollo di trasporto (SOAPWebServices)
• la definizione dell'interfaccia puo' essa stessa essere una
risorsa accedibile tramite Web
42
Piattaforma di elaborazione Web
Piattaforma client – Web Browser
• Protocol entity HTTP e SSL
• Interprete HTML, XML, XSLT, ...
• Architettura aperta plug-in/helper per la gestione di content-type
non built-in
• Integrazione di altri ASE e altre applicazioni di rete (e.g. mail)
• Interprete Java e Javascript
• API per accesso a WebServices
• API per accesso all'interfaccia locale di sistema
• Integrated Development Environment per la costruzione di
applicazioni
• Strumenti per la gestione della piattaforma (e.g. registrazione dei
certificati di autenticazione)
43
Piattaforma di elaborazione Web
Piattaforma server – Web/Application Server
• Protocol entity HTTP e SSL
• Name server per la gestione degli URL locali
• Interprete XSLT, PHP, Java, JSP, ...
• API per accesso a WebServices
• API per accesso all'interfaccia locale di sistema
• Integrated Development Environment per la costruzione di
applicazioni
• Strumenti per la gestione della piattaforma (e.g. registrazione dei
certificati di autenticazione)
44
Corrispondenze
• WebServices

Remote Procedure Calls
• WSDL

linguaggio RPCGEN

(basato su XDR)
(basato su XML)
• XML Schema

XDR
(entrambi definiscono sia un linguaggio per la definizione di sintassi
astratte che una sintassi di trasferimento)
• Protocollo SOAP
(specificato in XML)
• servizio di trasporto: HTTP

Protocollo Sun RPC

(specificato in XDR)

servizio di trasporto: TCP/UDP
• XML Schema basato su XML
 la sintassi di trasferimento e' rappresentata da XML
45