8 Www2009 Parte2

Parte 7

Modulo 5:
Client HTTP

World Wide Web
(Lato Client)

1

Browser
• Il browser è un’applicazione software che svolge il
ruolo di interfaccia fra l’utente ed il WWW,
mascherando la complessità di Internet.

• Diventa un client Web per recuperare informazioni
dai server Web.

• Funzioni principali
– instaura una connessione TCP con il server tramite
cui invia opportuni messaggi al server Web per
ottenere le risorse richieste
– interpreta il codice ipertestuale HTML
– elabora il codice allo scopo di visualizzare in modo
appropriato il contenuto delle pagine sullo schermo
Reti di Calcolatori 2009/2010 - World Wide Web 64

Breve storia
• FrameMaker e Acrobat PDF
– consentono generazione e incorporazione di iperlink.
• Gopher (University of Minnesota)
– primo browser con iperlink verso siti remoti
– uso di standard, quali testo ASCII e socket Unix
– difetti: link separati dal testo, immagini non gestite
HTML Mosaic
• Mosaic (NCSA, 1993)
Netscape
Microsoft Explorer (tramite Spyglass Co.)


2

Funzioni di un browser
• Richiedere la risorsa al server Web
– o attraverso un link presente su un'altra risorsa,
– oppure digitando direttamente il suo indirizzo nella barra
dell'indirizzo del browser
• Ricevere il file con la codifica della risorsa in
linguaggio HTML
• Decodificare ed interpretare secondo le specifiche di
HTML le caratteristiche grafiche, di formato e di
comportamento dei vari oggetti contenuti nella risorsa
(titoli, testi, immagini, pulsanti …)
• Visualizzare la risorsa sullo schermo del computer
dell'utente


Componenti di un browser

Interprete HTML
Controller
Input da mouse
e tastiera Driver
Output verso
Altro interprete lo schermo
(plug-in )

Client Http Client Http

Interfaccia di rete

Comunicazioni
con il server Web


3

Azioni di un browser (1)
Fase iniziale
• Il browser analizza l’indirizzo inserito esplicitamente nella finestra
indirizzo o l’iperlink selezionato nella pagina allo scopo di individuare la
risorsa specificata nell’URL.

• Controlla se la risorsa richiesta è contenuta nella cache disco del
browser. [mediante ricerca hash]
– Se la copia è valida, il browser la visualizza.
– Se l’utente ha esplicitamente effettuato un RELOAD, un buon browser
cercherà di risparmiare tempo effettuando solo una richiesta HTTP con
metodo GET al server con linea “If-modified-since” per controllare se la
copia nella cache è ancora valida o meno.

• Si passa alla fase successiva nel caso in cui l’oggetto vada acquisito.


Fase di lookup

• Il browser acquisisce dall’utente l’URL da richiedere.

• Il browser invoca il resolver per conoscere, tramite il
sistema di naming del DNS, l’indirizzo IP dell’URL
cercato.

 Se esistente, il DNS restituisce l’indirizzo IP.

Il lookup è quasi sempre implementato con una chiamata di
sistema bloccante, per cui il browser non può effettuare altre
operazioni fino a che l’operazione di lookup si conclude con
successo o insuccesso.


4

Fase di richiesta

 A questo punto, il browser attiva una connessione TCP con
l’host che ha l’indirizzo IP individuato.

 Sfruttando questa connessione, il browser richiede
mediante il protocollo HTTP la risorsa specificata nell’URL.

 Il server Web invia il file richiesto.

• Operazione di parsing:
– il browser analizza se vi sono oggetti allegati alla pagina
(embedded URL)
– in caso affermativo, il browser effettua una richiesta per ciascuna
risorsa collegata
(Ricordare la differenza tra protocollo HTTP/1.0 e HTTP/1.1)



Fase di visualizzazione
 Una volta inviati tutti gli oggetti (nel caso di protocollo HTTP/1.1) o
dopo aver inviato ciascun oggetto (protocollo HTTP/1.0), il server
chiude la connessione TCP.

 Non appena riceve il primo file, il browser analizza come
visualizzare sul monitor il testo contenuto nella pagina.

 Il browser carica e mostra gli eventuali oggetti allegati alla pagina.
Nel caso in cui l’oggetto ricevuto è in qualche formato non
direttamente interpretabile dal browser, questi può attivare un
apposito programma plug-in che ne consente la visualizzazione.


5

Software in esecuzione sulla
macchina client

DNS Resolver
HTML
Visualizzato dal
browser

JPEG
Web Web Tipo Visualizzato dal
server browser MIME browser grafico
(tipicamente, un
plug-in esterno)

Chemical
(Netscape API) Visualizzato da
opportuni programmi
Applicativo
client


Caching nel browser
• Il browser gestisce uno spazio disco (di dimensione predefinita) in cui
memorizza i file dei server Web recuperati corrispondenti a:
– pagine HTML
– immagini

• In realtà, prima di effettuare una richiesta al server Web (vedi “azioni di
un browser – fase 3”), il browser controlla se nella cache vi è una copia
dell’oggetto richiesto.
• L’utente può forzare il prelievo dell’oggetto dal server Web (bypassando
la cache del browser) mediante un opportuno pulsante del browser:
– REFRESH/AGGIORNA (Microsoft Explorer)
– RELOAD/RICARICA (Netscape Navigator)
• Gli oggetti nella cache possono avere un timestamp che indica il
periodo di validità dell’oggetto (stabilito dal server). Il client
eventualmente, effettua una richiesta if-modified-since al server Web.


6

Parte 9

Modulo 6:
Server HTTP

Macro-componenti del Web

Client oggetto Web (5)
browser
richiesta URL
(4)
INTERNET
(1) server Web
(3) 144.55.62.18

144.55.62.18 root
(2) name server

www.unimo.it?
name server
locale name server autoritativo
per www.unimo.it


7

Web come interfaccia universale
• Il Web da servizio di rete autonomo è divenuta
l’interfaccia preferita per moltissimi servizi informatici:
– Lettura e-mail
– Accesso a sistemi informativi aziendali
– Compilazione e sottomissione form (anche prenotazioni)
– …

• Ne consegue che il Web è un elemento critico per molti
altri aspetti “sociali”:
– Sicurezza e privacy delle informazioni
– Distribuzione e Copyright dell’informazione digitale
– Commercio elettronico
– …


Componenti di un sito Web
• Piattaforma hardware
• Software di base
• Server Web
– Il processo server HTTP ed il relativo software che
viene eseguito sulla piattaforma stabilisce il
collegamento tra la piattaforma (hardware - software
di base) e la parte informativa del sito Web.
• Parte informativa e servizi del sito Web
– Il sito deve mettere a disposizione un insieme di
risorse Web che possono essere richieste dai client
con cui vengono instaurate delle connessioni HTTP.


8

• Server Web


Parte informativa
• Generalmente organizzata in risorse iper-mediali con link
verso altre risorse (interne ed esterne al sito Web).

• L’organizzazione delle pagine è tipicamente gerarchica
ad albero, in cui vi è un punto di partenza e tutte le altre
pagine sono poste al di sotto della radice dell’albero.

• L’albero delle pagine Web è organizzato in modo
simile ad un file system gerarchico con una radice e
directory che contengono altre directory o file.


9

Organizzazione delle pagine (1)
• Ogni pagina Web ha un nome unico, che corrisponde al
cammino assoluto dalla radice “/” dell’albero delle
pagine.
(Questo cammino è proprio quello specificato nella parte
pathname dell’URL richiesto dal client.)

File system del server

Albero delle pagine
del sito Web



• L’albero delle pagine Web non riflette necessariamente
la vera organizzazione dei file all’interno del file system.

• L’organizzazione fisica che rispecchia fedelmente
quella logica è solo una delle possibili alternative.

• Per motivi di efficienza organizzativa (gruppi differenti
possono creare o fornire le informazioni per le pagine) o
di efficienza nella risposta, l’albero delle pagine Web può
essere partizionato tra due o più dischi della stessa
piattaforma o addirittura tra piattaforme differenti,
utilizzando o meno meccanismi di Network File System.


10

• Mirroring
– l’intero albero è replicato su più dischi o piattaforme

• Soluzioni intermedie
– le parti superiori dell’albero, ovvero le pagine più frequentemente
richieste, sono replicate
– le altre pagine possono essere o meno partizionate

Ciascuna di queste organizzazioni deve essere
trasparente per l’utente, che deve poter navigare e
richiedere le pagine nello stesso identico modo,
indipendentemente dall’organizzazione fisica dei file e dei
servizi Web.


Tipi di risorse - 1
(classificazione sulla base del contenuto)
• pagina HTML
• testo in formato ASCII
• pagina preformattata (come PostScript, PDF)
• immagine in diversi formati (tipo GIF, JPEG)
• suono codificati in diversi formati (quali AU, AIFF, MP3)
• video in diverse rappresentazioni (quali Quicktime, MPEG)
• rappresentazione VRML di scene tridimensionali
• codice eseguibile in linguaggi interpretati (tipo Perl e shell)
• codice eseguibile in linguaggi compilati, tipo C
• codice Java


11

Tipi di risorse - 2
(classificazione funzionale)
Risorse statiche
pagine il cui contenuto è relativamente stabile nel tempo.
Risorse volatili
pagine il cui contenuto viene modificato da eventi in corso.
Es., ultime notizie, avvenimenti sportivi, titoli in borsa.
Risorse dinamiche
pagine il cui contenuto è creato dinamicamente sulla base
della richiesta del client. Es., CGI.
Risorse attive
pagine in cui il server Web invia un applet Java al browser,
che esegue il contenuto sulla piattaforma client.


• Server Web


12

Fasi di una comunicazione TCP

• Dichiarazione al sistema operativo che si intende instaurare
una connessione con specifica delle caratteristiche

• Apertura della connessione (differente dal lato server
rispetto al lato client):
 il server assume di definire la connessione prima del client, e
rimane in attesa che il client si connetta alla porta specificata
 il client assume che il server sia già attivo e prova a connettersi
specificando indirizzo e porta del server

• Scambio di dati bidirezionale (trasmissione e ricezione)
• Chiusura della connessione


Server HTTP (es., richiesta oggetto statico)
Client (browser) DNS Server HTTP
Coda Coda
DNS lookup SYN-RCVD ACCEPT

Listen
Socket

ACCEPT

CPU
memoria
disco


13

Gestione richieste multiple
• Il server deve specificare una porta che identifica
il servizio sull’host
• Tuttavia, più client possono richiedere il servizio
in rapida successione
• Due soluzioni:
– Accodamento della richiesta client arrivata dopo
Gestito automaticamente dal sistema operativo; il processo
server deve specificare solo la lunghezza (backlog) della
coda

– Gestione contemporanea di più richieste client
Possibile mediante la gestione del multitasking da parte del
sistema operativo


Tre modalità di gestione richieste HTTP
Piattaforma
client
Browser
Richiesta Richiesta
http http Risposta
(1) Richiesta Risposta (i) http
Risposta http
http http
Processo (a) (c) processo
server (4) listener-dispatcher
(b)
(2) fork thread 1 (ii) (iv)
thread 2
helper 1
Processo thread 3
(iii) helper 2
figlio thread 4
helper 3

Metodo fork Metodo multithread Metodo helper

(3)
Apache 1.3.x
Piattaforma
server Apache 2.x

14

Un problema apparente ...
• Una porta viene assegnata ad un servizio, ma nel caso del
multitasking vi potrebbero essere più processi server attivi
• D’altro canto, le richieste di un client devono essere inviate
al processo server corretto

• Soluzione:
Usare sia le informazioni del server sia le informazioni
del client per indirizzare i pacchetti
• Il TCP usa 4 informazioni per identificare una connessione:
– indirizzo IP del server
– numero di porta del protocollo lato server
– indirizzo IP del client
– numero di porta del protocollo lato client


Software per server Web


15

Parte 9

Modulo 7:
Server HTTP – parte informativa

Sito “statico”: Sintesi azioni server Web
Il compito del server che fornisce pagine Web
statiche è molto semplice:
– attendere da parte dei browser richieste di connessione
TCP attraverso cui ricevere una richiesta HTTP
– decifrare il campo pathname dell’URL della richiesta
per determinare il file cercato
– controllare se il file è disponibile
– in caso affermativo, spedire il file al browser attraverso
la connessione TCP aperta
– chiudere la connessione subito dopo aver inviato
l’ultimo pacchetto concernente il file (nel caso di
protocollo HTTP/1.0)


16

Architettura del sito Web “statico”

Client oggetto Web (5)
browser
richiesta URL Server HTTP
Sistema operativo
(4)
INTERNET
(1) DATI
(3)
sito Web
144.55.62.18 root
(2) name server
www.unimo.it?
name server
locale name server autoritativo
per www.unimo.it


Risorse dinamiche
Alcune risorse Web non sono file multimediali, ma
programmi da eseguire. L’utente non ha bisogno di
rendersi conto che l’URL richiesto corrisponde ad un
programma, in quanto il server trasmette al client il
risultato dell’esecuzione e non il programma.
Possibili utilizzi:
• Creazione di pagine personalizzate dinamicamente nel momento in
cui vengono richieste in base a diversi parametri (es., dati client,
ora/giorno, stato del sistema)
• Accesso ad informazioni gestite da server non HTTP, come i database
• Interrogazioni a motori di ricerca
• Interazione personalizzata tra utente e server, che consente all’utente
di effettuare accessi riservati, ricerche, acquisti e transazioni


17

Architettura di un semplice sito
Web “dinamico”

Client
browser
oggetto Web
richiesta URL Server HTTP Data Base
Sistema operativo SO

DATI

Sito Web

Le architetture e tecnologie per siti Web dinamici sono alla
base dei servizi offerti via rete più complessi e “a rischio”


Classificazione delle tecnologie
• Tecnologie che prevedono processi esterni al processo
server HTTP
– Tecnologia Common Gateway Interface (CGI)
– Servlet Java

• Linguaggi di scripting (codice inserito nelle pagine
HTML ed interpretato direttamente dal server HTTP)
– Active Server Pages (ASP, Microsoft)
– PHP
– Java Server Pages (JSP, Sun)

• Tecnologie distribuite ad oggetti
– Tecnologia distribuita ad oggetti (CORBA)
– Java2 Enterprise Edition (J2EE)
– Microsoft .NET

18

Parte 8

Modulo 8:
Evoluzione del “Web
dinamico”

Motivazione
• Il Web trascende la sua funzione di tecnologia per
– semplificare il request/reply di file statici (get)
– facilitare il reperimento di file (navigazione point&click)

• Per diversi motivi, la tecnologia Web è ormai
l’interfaccia eletta per l’interazione della maggior parte
(tutti?) dei servizi che si possono usufruire via rete:
– interrogazioni: a database, a motori di ricerca, …
– comunicazioni: posta elettronica, blog, …
– download/upload file
– fruizione di contenuti multimediali
– svariati applicativi: dai gestionali in su
–…


19

Evoluzione
• Terminale “stupido” di mainframe Dipendenza totale

• Client/server, dove il client va Forte interazione
inteso come software specifico
per interagire con quel server.
Forte interazione tra i due
software.

• Il client diventa un software
browser-like e il server è in grado Interazione lasca
di rispondere

• Web services Completo svincolo


Possibili utilizzi

• Creazione di pagine personalizzate dinamicamente nel
momento in cui vengono richieste in base a diversi
parametri (es., dati client, ora/giorno, stato del sistema)
• Accesso ad informazioni gestite da server non HTTP,
come i database ed altre applicazioni
• Interrogazioni a motori di ricerca
• Interazione personalizzata tra utente e server, che
consente all’utente di effettuare accessi riservati, ricerche,
acquisti e transazioni

 Il Web come interfaccia di servizi sempre più sofisticati


20

Una prima architettura per siti
Web “dinamici” (non è solo così!)

Client
browser
oggetto Web
richiesta URL Server HTTP Data Base
Sistema operativo SO

DATI

Sito Web

Le architetture e tecnologie per siti Web dinamici sono alla
base dei servizi offerti via rete più complessi


Risorse dinamiche

• Alcune risorse Web non sono file multimediali,
ma richiedono l’esecuzione di (uno o più)
programmi
• L’aspetto importante è che l’utente non ha
bisogno di rendersi conto che l’URL richiesto
corrisponde ad un programma né che vi sia
l’interazione con due o più server, in quanto il
server HTTP trasmette il risultato
dell’esecuzione e non il programma ( risorse
attive)
 RICORDARE L’OBIETTIVO TRASPARENZA

21

Livelli logici di un servizio Web-based
• In un servizio si possono approssimativamente
distinguere, a livello logico, le seguenti componenti:
– Interfaccia utente, che rappresenta ciò che l’utente
percepisce attraverso i propri sensi interagendo con
l’applicazione
– Logica di presentazione, che rappresenta quello che
accade quando l’utente interagisce con l’interfaccia
– Logica dell’applicazione, cioè le operatività cui è
preposta l’applicazione (business logic)
– Logica dei dati, cioè la gestione fisica dei dati
(aggiornamenti e ricerche), compresa la loro validazione
attraverso verifiche di completezza ed integrità


Importante
Non confondere i “livelli logici” con i
“processi” che realizzano i livelli logici e con i
“computer” che eseguono i processi.
Quindi,
– Livelli logici
– Processi
– Computer


22

Alternative per mappare 4 livelli logici
sui processi
• Tutto su di un processo (teorico)
• Con due processi distinti
– Processo client: gestisce il livello “interfaccia utente”
– Processo server: gestisce i 3 livelli (presentation, application, data)
• Con tre processi distinti
– 1° processo server: gestisce i livelli presentation e application
– 2° processo server: gestisce il livello data
• Con quattro processi distinti
– 1° processo server: gestisce i livelli presentation
– 2° processo server: gestisce il livello application
– 3° processo server: gestisce il livello data

Alternative per mappare 2 o più
processi su 2 computer
Esempio (2 processi – 2 computer)




23

Alternative per mappare 4 processi
su 2 o più computer (cont.)




Evoluzione architetture lato Web server

Front-end Router/
HTTP Firewall
server(s) (Presentation
HTTP LAN
server(s) (Presentation logic)
logic) Web
application (Business logic)
server(s)
HTTP (Presentation
server(s) logic)
Back-end (Data logic - Back-end (Data logic -
server(s) DB server) server(s) DB server)

Web
(Business
application
logic)
server(s)

Back-end (Data logic -
server(s) DB server)


24

Livello Presentation logic
• Agisce come un’interfaccia tra il livello di
interfaccia utente e la business logic

• Implementato mediante:
– HTTP server
 Apache
 Microsoft IIS
– (eventuali) Business-logic plugins


Livello Data logic
• Gestisce dati strutturati su supporti di
memoria permanente

– Database Management systems
 Microsoft Sql server
 IBM DB2
 Oracle
 MySql (open source) - Sun  Oracle
 Postgress (open source)
…


25

Livelli definiti: Presentation & Data

HTTP (Presentation
Front tier server logic)

Middle tier
? (Business
logic)

Back-end (Data logic)
Back-end tier server


Livello Business logic
• Il più interessante e in continua evoluzione

• PROSSIMO OBIETTIVO
Analizzare le tecnologie software che
consentono la realizzazione di cosiddetti
sistemi Web multi-livello (multi-tier) per
realizzare servizi (non solo siti) Web-based
dinamici


26

Tecnologie principali per middle tier

1. Tecnologie che prevedono processi esterni al
server HTTP

2. Linguaggi di scripting

3. Tecnologie distribuite ad oggetti


Tecnologie per middle tier (I)
• Tecnologie che prevedono
processi esterni al server
HTTP
HTTP
– basate su Common Gateway server(s) (Presentation
logic)
Interface (CGI): script in C o Perl Web
(Business
application
(molto popolare, perché?) server(s) logic)
– il server HTTP crea un nuovo
processo per il programma CGI che Back-end (Data logic -
dovrà essere eseguito ( copia server(s) DB server)
programma, allocazione memoria,
ambiente di variabili separato, ecc.)
 TECNOLOGIA NON SCALABILE CGI-based
(per un server che deve gestire molte (Presentation+
richieste, questo è inaccettabile) Business processi
separati)

27

Tecnologia CGI
(primo standard de facto per applicazioni)
Come garantire che il server e lo script possano
interagire correttamente tenendo conto che i due
software sono tipicamente implementati da persone
differenti in linguaggi potenzialmente diversi?

• Una soluzione è lo standard proposto da NCSA
Common Gateway Interface (CGI)
che specifica
– come gli script devono essere invocati
– come devono essere passati i dati dal processo server allo script e viceversa

• Lo standard CGI svolge tra processo server e script lo stesso ruolo
che il protocollo HTTP svolge tra browser e processo server
• Lo standard è storicamente importante: spesso script e gateway
vengono chiamati rispettivamente script CGI e gateway CGI


Primo passo di evoluzione
• Se il problema è la scalabilità limitata
• Se il limite alla scalabilità è dovuto
principalmente alla necessità e al costo di
attivazione di un nuovo processo per ogni
richiesta dinamica

• Si aumentino le prestazioni, mediante l’utilizzo
di tecnologie che evitino la creazione di un
nuovo processo  Tecnologie di scripting


28

Tecnologie per middle tier (II)
• FastCGI: permette di
condividere un’istanza di un
programma CGI
• Server API (Netscape NSAPI, HTTP
(Presentation
MS ISAPI): Librerie condivise server(s)
Logic +
caricate nello spazio del server Web
application
Business logic)

HTTP, in grado di servire server(s)

richieste multiple senza creare
nuovi processi  poca Back-end (Data logic,
server(s) DB server)
portabilità (legate al server
HTTP) e vulnerabili (thread safe)
• ColdFusion
(Presentation+
Business integrati)


Tecnologie per middle tier (II bis)

• Linguaggi di scripting HTTP
(Presentation
server(s)
– codice inserito nelle pagine Web
Logic +
Business logic)
application
HTML ed interpretato server(s)
direttamente dal server HTTP,
ma meno legato a uno Back-end (Data logic -
DB server)
server(s)
specifico server HTTP

(Presentation+
Business integrati)


29

Alcuni linguaggi di scripting
• Active Server Pages (ASP, MS): scritte in HTML +
VBScript  Soluzione specifica per server HTTP (IIS),
problemi di manutenibilità del software HTML/script
integrato
• Java servlets (Sun): programmi server side in grado di
servire multiple richieste HTTP con un solo processo
(come un applet multi-thread eseguito lato server) 
basato su JVM: portabile, non efficiente
• Java Server Pages (JSP, Sun): può combinare HTML,
Java e JavaBean
• PHP  “Programming Language of 2004” - Il
linguaggio delle architetture “open” LAMP (Linux,
Apache, MySQL, Php)


Altri linguaggi di scripting
“per intenditori”
• Perl: il linguaggio per il parsing, la gestione di stringhe
e espressioni regolari. Non difficile da apprendere,
molto difficile rendere efficienti le applicazioni

• Python: linguaggio di scripting a oggetti. Linguaggio in
crescita, sebbene molto oneroso dal punto di vista
computazionale e strettamente legato alla piattaforma
“Zope”

• Ruby: linguaggio di scripting a oggetti. Uno scalino di
apprendimento molto alto rispetto ad altri linguaggi di
scripting, ma dalle potenzialità enormi. In grande
crescita anche per la diffusione di framework quali
“Ruby On Rails” (ROR)

30

Secondo passo di evoluzione
• Con l’evoluzione tecnologica delle piattaforme hardware
(CPU, dischi, RAM, cache), l’aspetto prestazionale delle
applicazioni Web-based rimane un fattore importante, ma
aumentano anche le aspettative sui servizi che si vogliono
poter erogare via Web

• La complessità del middle tier aumenta considerevolmente
(non più solo accesso a un DB, ma a DB multipli, Insiemi di
file XML, directory service, ecc.)  si sviluppa una vera e
complessa business logic

• Applicazioni sempre più complesse  necessità di
modularità, portabilità (spaziale e temporale),
manutenibilità e possibilità di riutilizzo del software


Secondo passo di evoluzione (2)
• Le tecnologie di scripting, che mirano principalmente
all’aumento delle prestazioni, non soddisfano i nuovi
requisiti richiesti dalle nuove applicazioni software

• La business logic complessa rende necessario una
separazione dal processo server HTTP
Attenzione: Scopi diversi. Non è un ritorno al CGI!

• Qual è la tecnologia che più risponde ai requisiti di:
– Modularità
– Portabilità
– Manutenibilità
?

31

Tecnologie per middle tier (III)
• Tecnologie distribuite ad oggetti
– Ogni oggetto ha un’interfaccia
(insieme di metodi pubblici)
LAN
– Il codice può essere eseguito dove
serve (portabilità)
HTTP (Presentation
– Promuove la generalità: molte server(s) logic)

applicazioni possono usare
business object comuni
Web
– Migliora la manutenibilità: con (Business
application
logic)
buona interfaccia, cambiamenti server(s)

influenzano solo l’oggetto
Back-end (Data logic -
Distribuite a oggetti server(s) DB server)
(Presentation+
Business separati)

Nasce il Web Application Server
Web Application Server: “un Web server che ha una business logic”

Due note:
- la definizione non spiega granché
- si parla sempre di server (=processo)
non di computer!
HTTP (Presentation
Front tier server logic)

Web application (Business
Middle tier
server logic)

Back-end tier Back-end (Data logic)
server


32

Web Application Server (WAS)
• WAS
– Implementa la business logic del sito Web, ovvero tutte le
possibili funzioni che sottendono le operazioni “dinamiche”
– Traduce le richieste utente in operazioni che interagiscono
con applicativi e/o con il livello data logic

• A dir la verità, si esce dal concetto di tecnologia
per il solo “sito Web”  l’insieme delle
tecnologie Web viene utilizzata per interfacciarsi
all’intero SISTEMA INFORMATICO Web-based

– Tecnologie middleware (una miriade )

Due tecnologie attuali di successo e
una che non ce l’ha fatta
• CORBA (standard de jure degli anni ’90,
non è riuscito ad affermarsi)

• Open source SI ANALIZZERA’

Java2 Enterprise Edition (J2EE) - SUN

• Proprietaria
Articoli: J2EE vs .NET
.NET - Microsoft su Google


33

Parte 4

Modulo 6:
Cenni allo “storico” CGI
(Common Gateway Interface)

Script e Gateway
Meccanismi che consentono
• al client Web la capacità di eseguire un’applicazione sulla
piattaforma server
• al server Web di connettersi ad altri servizi e poter
recuperare informazioni dall’utente, eventualmente
mediante form interattive

• SCRIPT: definizione generica di un qualsiasi programma
eseguito dal server (tipicamente, ma non necessariamente
implementato in un lingua interpretato)

• GATEWAY: uno script che fornisce accesso ad un
servizio online (es., ad un database) svolgendo un ruolo
da interfaccia tra il server Web ed un altro server

34

Azioni di uno script/gateway

• Tradurre l’input del client (il file HTML proveniente dalla
connessione HTTP) in forma comprensibile ai servizi a cui
si collega (es., query nel linguaggio del database)

• Invocare l’attivazione di altri programmi eseguibili

• Tradurre l’output del programma in una forma
comprensibile al client (es., l’informazione restituita dal
database in un formato compatibile con il protocollo HTTP)


Implementazione di script
• Uno script Web, nella sua forma più generale, è un
qualsiasi programma che può essere eseguito dal server
in risposta ad una richiesta Web

• Non importa il linguaggio con cui lo script è implementato
– C/C++
– Perl
– TCL
– Unix shell
– Visual Basic
– Altri strumenti proprietari (AppleScript, …)

• L’importante è che sia in grado di leggere da STDIN,
scrivere su STDOUT e leggere le variabili ambiente


35

Suddivisione dello spazio server
Area
Browser WWW Il server fornisce file
(statici o volatili)

tipo
file
Il server esegue script CGI che
Area creano documenti dinamici
CGI

File system del server

Albero degli Albero delle pagine
eseguibili (“/cgi-bin/”) del sito Web (“/”)


Azioni del server HTTP
• Il server HTTP deve determinare che la risorsa richiesta nell’URL
non è una pagina Web, ma un programma.
• Il processo deve localizzare il programma e controllare se può
essere eseguito. Possibili scelte:
– directory /cgibin
– qualunque file abbia estensione .cgi in qualunque directory
– qualunque file abbia estensione .EXE (server su Windows NT)

• Nel caso in cui le precedenti operazioni siano andate a buon fine, il
server HTTP deve attivare il programma script e assicurare che
l’eventuale input proveniente dal browser sia passato allo script
• Il server HTTP deve leggere l’output dello script e passarlo al client,
ovvero deve inviare un messaggio di errore
• Il server HTTP deve chiudere la connessione nel momento in cui
l’esecuzione dello script è completata


36

Interazione tra browser e server HTTP

browser server
HTTP CGI

• Invocazione diretta di un URL
(METHOD=GET)
– l’utente specifica l’URL di un CGI
– l’utente seleziona un link all’URL di un CGI

• Invio di una “fill-in form”
– mediante METHOD=GET
– mediante METHOD=POST

Fill-in form
• Gli script/gateway acquisiscono l’informazione dall’utente
mediante una speciale pagina HTML detta fill-in form
inviata dal server alla macchina client
• Il browser visualizza il form all’utente come una normale
pagina HTML, ma in più raccoglie i dati di input inseriti
dall’utente
• Il browser rispedisce al server il fill-in form compilato

I form possono essere utilizzati per raccogliere vari tipi di informazioni,
come nome e password dell’utente per poter accedere ai siti Web ad
accesso limitato, o una o più parole chiave per consentire la ricerca in
database.
I form potrebbero anche essere embedded (es., imagemap o mappe
sensibili)


37

Tag <FORM> di HTML
<FORM> </FORM> Attributi:
METHOD=GET
METHOD=POST
ACTION=“http://www.unimo.it/cgi-bin/script.cgi”

<INPUT> Attributi:
TYPE=TEXT (input testuale)
TYPE=CHECKBOX (selezione)
TYPE=RADIO (selezione esclusiva)
TYPE=SUBMIT (tasto per inviare i dati)
TYPE=RESET (tasto per cancellare i dati)
NAME=“etichetta”
VALUE=“valore_associato” (se selezionato)
CHECKED (selezionato per default)

<SELECT> <OPTION>...</SELECT> (menù a tendina)
Attributi:
NAME=“etichetta”

Un esempio di Fill-in Form
un esempio di form
Dove studi?
Quale browser stai usando?
1) Netscape
2) Explorer

Submit Reset

<FORM METHOD=POST
ACTION= “http://www.dsi.unimo.it/cgi-bin/miofile”>
<P>Dove studi?
<INPUT NAME=“city” TYPE=text SIZE=“20”>
<P>Quale browser stai usando?
<P> Netscape <INPUT NAME=“brow” TYPE=radio VALUE=“netscape”>
<P> Explorer <INPUT NAME=“brow” TYPE=radio VALUE=“explorer”>
<P><INPUT TYPE=submit> <INPUT TYPE=reset>
</FORM>

38

Metodo GET
• L’informazione della fill-in form è inviata al server come
parte dell’URL, aggiungendo alla stringa URL una
QUERY_STRING, separata dal carattere “?”
• La query_string è composta da coppie “nome=valore”:
– nome è il nome della variabile
– valore è il valore assegnatole
• Ogni coppia “nome=valore” è separata dal carattere “&”. Es.,
/cgi-bin/script.cgi?city=modena&brow=netscape
• La query_string è “URL encoded” e si deve decodificare
• Lo svantaggio maggiore del metodo GET è che la
dimensione massima della QUERY_STRING è limitata dalla
dimensione dell’input buffer del server HTTP (tipicamente
fissata a 1024 byte)

Metodo POST
• L’informazione della fill-in form non è aggiunta
all’URL, ma viene inviata dopo tutte le informazioni
dell’header della richiesta HTTP

• In particolare, tra le informazioni dell’header vi è il campo
content-length, che contiene la dimensione (in byte)
dell’informazione inviata al server. In questo modo si
supera il problema maggiore del metodo GET

• Un altro vantaggio del metodo POST è la possibilità di
inviare informazioni anche non testuali (utilizzando
opportunamente il campo content-type)

• L’informazione viene passata dal server HTTP allo script
CGI mediante STDIN (si vedrà dopo)

39

Esempio: Metodo POST

POST /cgi-bin/script.cgi HTTP/1.0
Referer: http://www.spc.com/form.html
User-Agent: Mozilla/4.05 [en] (Win95; I)
Host: www.spc.com
Accept: image/gif, image/x-xbitmap, image/jpeg, */*
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8
Content-type: application/x-www-form-urlencoded
Content-length: 23

city=modena&brow=netscape


GET POST
Indicato per pochi Indicato per grandi
parametri (<1024 byte) quantità di dati

Solo parametri testuali Dati in qualsiasi formato
(testi, immagini, video)

Possibilità di inserire un
URL con parametri Solo in risposta ad una
opportuni all’interno di fill-in form
una pagina HTML.
Esempio:
<A HREF= “http://www.unimo.it
/cgi-bin/search?query=ingegneria>
Ricerca Facoltà Ingegneria </A>


40

URL encoding
• Caratteri quali spazi, slash, tilde, sono illegali in un
URL. Pertanto devono essere “codificati” per poter
essere trasmessi dal browser
• Spazio --> “+”
Esempio:
Campo “nome” in una form: John Smith
www.unimo.it/cgi-bin/script.cgi?myname=John+Smith
• Caratteri illegali --> “%codice ASCII esadecimale”
Esempio:
Campo “file” in una form: ~filename
www.unimo.it/cgi-bin/script.cgi?myfile=%7Efilename

• Sarà compito del programmatore dello script CGI
“decodificare” l’URL prima di utilizzarne i valori


Interazione tra server HTTP e CGI

browser server
HTTP CGI

• Nel momento in cui un client richiede ad un server di lanciare un CGI,
può anche passargli delle informazioni da fornire al CGI. Esistono 3
modalità per passare parametri dal server HTTP allo script CGI:
– Variabili ambiente
– Argomenti linea di comando
– Standard input

• Esiste un modo per passare risultati dallo script CGI al server HTTP:
– Il CGI invia il risultato dell’elaborazione sempre sullo standard
output verso il server HTTP, che a sua volta prepara i dati e li
rispedisce al client.


41

Variabili ambiente
• Una variabile ambiente è un parametro con un nome per
trasferire informazioni dal server allo script CGI. Non è
necessariamente una variabile dell’ambiente del Sistema
Operativo, anche se questa è l’implementazione più comune.
• Esempi (rappresentazione canonica: “maiuscole_maiuscole”):
– SERVER_SOFTWARE, nome e versione del server
– SERVER_NAME, hostname o indirizzo del nodo server
– GATEWAY_INTERFACE, versione CGI (uso: CGI/1.1)
– QUERY_STRING, informazione contenuta dopo il ? nell’URL
– REQUEST_METHOD, metodo della richiesta HTTP (GET, PUT, …)
– REMOTE_ADDR, indirizzo IP del nodo client che effettua la richiesta
– REMOTE_USER, se lo script è protetto da autenticazione utente
– CONTENT_TYPE, per query HTTP POST e PUT
– CONTENT_LENGTH


Input 1: Variabile ambiente QUERY_STRING
• Il client aggiunge nell’URL un campo query
“nome1=valore1&nome2=valore2&…” separato dal resto
dell’URL mediante il carattere “?”. Ad esempio,
GET http://www.unimo.it/cgi-bin/corsi.cgi?attr1=val1&attr2=val2 HTTP/1.0

• Il server HTTP esegue corsi.cgi dopo aver inserito la stringa
“attr1=val1&attr2=val2”
nella variabile ambiente QUERY_STRING

• Nello script CGI corsi.cgi ci dovranno essere:
– un’istruzione del tipo: char * str = getenv("QUERY_STRING");
– le istruzioni per la decodifica della stringa, in formato URL encoded
– le istruzioni per il parsing della stringa

42

Input 2: Argomenti linea di comando
• Metodo semplice, ma non molto utilizzato per script CGI
• Utile, tuttavia, quando si vogliono passare pochi parametri
(uno, due) senza dover effettuare il parsing di una stringa.
• Utilizzate, ad esempio, per richieste di tipo ISINDEX, per
ricerche di testo nei file.

• Le parole da ricercare sono inserite direttamente nell’URL,
senza utilizzare il formato “nome=valore”.

• Esempio 1 (linea di comando)
– http://www.dsi.unimo.it/cgi_bin/corsi.cgi?impianti
• Esempio 2 (variabile di ambiente QUERY_STRING)
– http://www.dsi.unimo.it/cgi_bin/corsi.cgi?corso=impianti


Passaggio mediante linea di comando
• Il client aggiunge nell’URL un campo query separato dal
resto dell’URL mediante il carattere “?”. Ad esempio,
GET http://www.unimo.it/cgi-bin/corsi.cgi?valore1+valore2 HTTP/1.0

• Il server HTTP esegue corsi.cgi valore1 valore2

• Nello script CGI corsi.cgi i parametri passati sulla linea di
comando potranno essere recuperati mediante tipiche
istruzioni C:
main(int argc, char** argv)
{ …
argv[1]; /* contiene valore1 */
argv[2]; /* contiene valore2 */
…
}

43

Input 3: Standard input
• Metodo possibile solo quando l’applicativo CGI viene
invocato mediante i metodi POST o PUT dell’HTTP
(utilizzati per completare la fill-in form)

• Il corpo della richiesta del client inviata al server HTTP
viene ridiretto dal server sullo standard input dello
script CGI

• Il numero di byte è nella variabile ambiente
CONTENT_LENGHT, mentre il tipo dei dati MIME è nella
variabile di ambiente CONTENT_TYPE

• Anche in questo caso, l’informazione trasferita dal metodo
POST è URL encoded e deve essere decodificata


Passaggio mediante standard input
• Il client invia una richiesta del tipo:
POST http://www.unimo.it/cgi-bin/corsi.cgi HTTP/1.0
…
(linea vuota)
attr1=valore1&attr2=valore2

• Il server HTTP passa i parametri a corsi.cgi tramite lo standard
input

• Nello script CGI corsi.cgi ci dovranno essere:
– un’istruzione del tipo: scanf(“%s”, stringa);
oppure un’istruzione del tipo: char c=getchar( );
– le istruzioni per la decodifica della stringa, in formato URL encoded
– le istruzioni per il parsing della stringa

44

Input a CGI (riepilogo)

BROWSER METHOD HTTP SERVER-->CGI

Invocazione URL GET (senza =) Linea comando

Invocazione URL GET (con =) Variabili ambiente

Invio form GET (con =) Variabili ambiente

Invio form POST Standard input


Output da CGI

• Quando il server HTTP restituisce un oggetto (statico o
dinamico) al client, include nell’header di risposta alcune
informazioni sull’oggetto.
Queste informazioni sono inviate indipendentemente
dal risultato dell’applicazione CGI.

• Lo script CGI può aggiungere tre tipi di informazione:
– Tipo del contenuto: formati standard MIME
– Posizione: alternativa per localizzare l’oggetto
Location: URL
– Status: risposta HTTP
Status: XXX message


45

Esempio
http://www.dsi.unimore.it/cgi-bin/phone
#!/bin/sh
Un semplice esempio di script echo Content-type: text/html
if [ $# = 0 ]
shell che accede al file Unix then
echo "<HEAD>"
/apps/data/Phone_Directory echo "<!-- Written by B Kelly --!>"
echo "<TITLE>Search Phone Directory</TITLE>"
mediante il comando grep. Per echo "<ISINDEX>"
echo "</HEAD>"
trovare il numero telefonico echo "<BODY>"
della persona specificata nella echo "<H1>University Phone Directory</H1>"
echo "Enter name of the person in the box.<P>"
prima parte (fill-in form). echo "</BODY>"
else
echo "<HEAD>"
echo "<TITLE>Results of Search</TITLE>"
Si noti l’uso di tag HTML per la echo "</HEAD>"
creazione e la visualizzazione echo "<BODY>"
echo "<H1>Results of Search for $* </H1>"
del testo con layout. echo "<PRE><TT>"
grep -i "$*" /apps/data/Phone_Directory
echo "</PRE></TT>"
echo "</BODY>"
fi

Reti di Calcolatori 2009/2010 - World Wide Web 7.152

1. Esecuzione script (azione client)
• Il browser, dopo aver localizzato l’indirizzo IP del computer
corrispondente all’hostname www.dii.unimore.it, attiva una
connessione TCP sulla porta 80 del server.

 Una volta stabilita la connessione TCP, il client invia la richiesta per
conoscere il numero di telefono di un docente del DII.

Esempio:
GET /cgi_bin/phone HTTP/1.0
Connection: close
User-agent: Mozilla/4.0
Accept: text/plain
Accept: text/html
Accept: image/*


46

2. Esecuzione script (informazioni)
 Il server riceve la stringa dal client e decodifica la richiesta
secondo le regole del protocollo HTTP/1.0 per determinare le
azioni da intraprendere

 La richiesta contiene quattro importanti informazioni:
– il metodo (GET) che specifica le azioni, ovvero localizzare il file,
leggerlo da disco, eseguirlo, e trasmettere il risultato al client
– la connessione deve essere chiusa dal server, dopo aver inviato
l’ultimo pacchetto
– il pathname dello script CGI (/cgi_bin/phone) da eseguire
– la versione del protocollo utilizzato dal browser

 La richiesta contiene anche delle meta-informazioni sul browser:
– browser utilizzato (es., versione 4.2 di Netscape)
– configurazione (es., configurato per visualizzare testo ASCII, file
HTML ed immagini codificate in qualsiasi modo)


3. Esecuzione script (esecuzione)

browser Server
HTTP
phone
(CGI)
Piattaforma client

grep
(Unix)
Piattaforma server


47

4. Esecuzione script (risposta OK)
• Assumendo che non si sia verificato alcun errore, il server invia il
codice del risultato del metodo eseguito.
• A differenza del caso in cui la richiesta era per una pagina statica,
in questo caso il server Web non valuta il “Content-type” né il
“Content-length”, in quanto è lo script stesso che determina il tipo
di informazione restituita:
HTTP/1.0 200 OK
Server: Apache/1.3.0 (Unix)
Date: Thu, 29 Apr 2000 11:21:00 GMT

• Lo script si occupa di determinare la seconda parte dell’header,
seguita dalla pagina di risposta costituita dall’output del processo
“grep”:
Content-type: text/html
< … dati del processo grep ... >


5. Esecuzione script (risposta NO)
• Nell’ipotesi in cui il file non sia trovato o non sia eseguibile, la
richiesta non può essere soddisfatta ed il codice di risposta è “404
– Not found” e la risposta del server è del tipo:

HTTP/1.0 404 Not found
Server: Apache/1.3.0 (Unix)
Date: Fri, 14 Jan 2000 12:30:00 GMT
Content-length: 0

• Nell’ipotesi in cui lo script “phone” sia individuato, ma la sua
esecuzione generi un errore (es., non viene trovato il processo
Unix “grep”), la risposta è:
– “200 – OK” perché il processo sta restituendo qualche informazione.
– Tuttavia, l’informazione restituita sarà un messaggio di errore del tipo
“Cannot find grep command on this system”.


48

Inserire altre informazioni nell’URL
• URL può avere anche degli argomenti che contengono informazioni

• Gli argomenti vengono inseriti dopo il pathname dello script CGI e
sono separati da punti interrogativi. Es.,
#!/bin/sh
echo Content-type: text/html
N=$QUERY_STRING
echo "<HTML>"
case "x$N" in
x) N=1
echo "This is the initial page.<BR><BR>"
;;
x[0-9]*) N=‘expr $N + 1‘
echo "You have displayed this page $N times.<BR><BR>"
;;
*) echo "The URL you used is invalid.</HTML>"
exit 0
;;
esac
echo "<A HREF="http://$SERVER_NAME$SCRIPT_NAME?$N">"
echo "Click here to refresh the page.</A> </HTML>"


Esempio di esecuzione (1)
• Documento iniziale

<HTML>
This is the initial page.<BR><BR>
<A HREF="http://www.nonexist.com/cgi/ex4?1">
Click here to refresh the page.</A> </HTML>

• Risultato

This is the initial page.
Click here to refresh the page.


49

Esempio di esecuzione (2)
• Output generato


<HTML>
You have displayed this page 2 times.<BR><BR>
<A HREF="http://www.nonexist.com/cgi/ex4?2">
Click here to refresh the page.</A> </HTML>

• Risultato

You have displayed this page 2 times.
Click here to refresh the page.


Esecuzione
1. Il server capisce che l’URL richiesto è un CGI

2. Istanzia un processo che esegue il CGI
– Il processo a sua volta crea un nuovo
processo che esegue il comando grep

3. Invia l’output dello script al client


50

Sicurezza
• Controllare sempre input degli utenti

• Cosa succede se invoco l'URL ''phone.cgi?;rm''
– grep $1 /apps/data/phone.txt
– Diventa:
– grep ;rm /apps/data/phone.txt

• Molto meglio racchiudere $1 tra apici


Configurazione CGI
• In Apache si usa la direttiva ScriptAlias
– ScriptAlias URL Path
– es., ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

• Alternativa:
– AddHandler cgi-script cgi pl
– Option +ExecCGI


51

CGI: Pro e Contro
• Vantaggi
– Semplice da programmare
– Indipendente dal linguaggio e dalla piattaforma
– Primo standard de facto per il Web dinamico

• Svantaggi
– Poco efficiente nelle prestazioni: è necessario eseguire
una FORK-EXEC per ogni richiesta
– E’ difficile verificare e garantire la sicurezza
(es., l’applicazione CGI viene lanciata dal processo server, con i
privilegi di quest’ultimo)


52

8 Www2009 Parte2

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie 8 Www2009 Parte2

Ähnlich wie 8 Www2009 Parte2 (20)

Mehr von Majong DevJfu

Mehr von Majong DevJfu (20)

8 Www2009 Parte2