Tecnologia di Internet
 
Scripting Server Side 1: Form CGI, SSI
Il compito più semplice di un web server consiste nel fornire pagine HTML statiche. Per incrementare la potenza del server e dargli la possibilità di fornire pagine dinamiche, (cioè create sul momento, con dati variabili) o semplicemente amministrare il server possono essere usate alcune tecnologie server-side che essenzialmente fanno tutte la stessa cosa. Il funzionamento generale di un server web, considerando anche la tecnologie server-side, è il seguente
  • Mediante una interfaccia utente, vengono raccolti i dati per interrogare il web server; i dati introdotti sono una query, una richiesta per il web server (ricerca in un database, ordine di un libro, richiesta di un file)
  • I dati vengono trasmessi al web server
  • I dati vengono elaborati da parte del web server utilizzando middleware
  • I risultati vengono trasmessi al browser che li visualizza; la visualizzazione può ridursi all’interpretazione dell’HTML o essere una manipolazione più complessa (calcolo, ordinamento)

Questa descrizione comprende anche il caso più semplice, quello di una pagina statica. Un utente chiede al browser di contattare un server mediante il protocollo HTTP, e di richiedere uno specifico documento HTML. Il documento viene trasmesso dal server e viene ricevuto e visualizzato dal browser.

Un esempio un po’ più complesso. Un utente fornisce dei parametri di ricerca mediante un form HTML che il browser spedisce al server mediante una connessione SSL. Il server processa i dati con uno script CGI connettendosi ad un database e facendo una ricerca sulla base della richiesta dell’utente e ritrasmette i risultati che vengono visualizzati in una.tab nella finestra del browser.

Un esempio ancora più complesso. Abbiamo un client Java che manda una richiesta criptata ad un Java Web Server, il quale processa la richiesta con un Java servlet che usa un oggetto CORBA per generare dati finanziari in forma XML con un foglio stile XSL che viene spedito al Java client per essere scansionato in un XML Tree e visualizzato secondo XSL.

Le tecnologie utilizzate per le applicazioni web possono essere inquadrate in uno schema a livelli di questo tipo
Le diverse tecnologie per lo sviluppo di una applicazione web possono essere classificate con questo schema a livelli.
Con questo schema possono essere classificate numerose tecnologie, ognuna delle quali ha la sua sintassi, i suoi procedimenti, punti di forza e di debolezza. Nella figura che segue sono riassunte le principali tecnologie utilizzate.
Principali tecnologie per lo sviluppo di applicazioni web classificate secondo lo schema a livelli (da Selene Sol).

Riferimenti online

Dopo questa introduzione, in questa prima pagina dedicata allo scripting server-side trattiamo di queste tecnologie:
  • Form HTML
  • Common Gateway Interface
  • Server Side Include

mentre nella pagina successiva vedremo

  • Microsoft Active Server Pages
  • BlueWorld Lasso
  • Server-Side Java
Form HTML
Nella pagina precedente abbiamo già visto alcune delle tecnologie a livello comunicazione e a livello browser. Discutiamo qui i form HTML perché sono in stretta relazione con gli argomenti di questa lezione.

L’interattività di base tra utente e web si ottiene mediante l’uso dei form (moduli) HTML. I tag HTML che definiscono un modulo consentono di progettarlo che l’utente possa riempirlo con i propri dati e trasmetterlo al server. Il modulo comprende campi, pulsanti, menù a tendina e così via.
Esempio di form (modulo) che l’utente riempie con dati che, facendo clic sul pulsante Submit, vengono trasmessi al server.
Common Gateway Interface
Un Common Gateway Interface, in breve CGI, stabilisce come browser e server trattano le informazioni che provengono da form HTML. In senso lato, CGI è spesso usato con il senso di “qualunque programma che gira a fianco di un web server e interagisce con esso”. Un CGI può essere sincrono o asincrono (ACGI). Un ACGI lavora indipendentemente dal web server (non sono obbligati ad aspettarsi a vicenda).

Come si è già detto, il compito più comune di un web server consiste nel trasmettere pagine HTML statiche, già preparate. Se sul web server gira un programma che può eseguire qualche azione e successivamente spedire una pagina al browser, la pagina può essere in qualche modo attiva, cioè contenente risposte personalizzate o comunque aggiornate. Per esempio può visualizzare un contatore (quante volte è stata vista questa pagina), oppure può visualizzare le quotazioni di borsa (che continuano a cambiare) o le previsioni del tempo aggiornate. Invece di trasmettere passivamente il contenuto di pagine preventivamente preparate, le specifiche CGI consentono di servire documenti diversi secondo le richieste del client.

Gli script (o gateway) CGI sono piccoli programmi che possono essere scritti in qualunque linguaggio di programmazione (il più usato è Perl) e che vengono eseguiti sul server (per questo sono detti server-side). In questo senso sono in contrapposizione con gli script client-side come gli applet Java, gli script JavaScript, e i controlli ActiveX.

Gli script CGI vengono utilizzati per

  • accedere a informazioni da fonti diverse dal web, per esempio da un database
  • consentire una interazione tra utente e server, per esempio consultare un catalogo e fare acquisti
  • creare documenti personalizzati al volo, cioè nel momento in cui il client fa la richiesta

Quando un browser richiede l’URL di un qualcosa che non è un file ma uno script CGI, il server esegue lo script (passandogli i dati che arrivano da un form o mediante un URL) e restituisce il risultato.

In che modo il server web sa quali documenti sono da eseguire e quali le informazioni da trasmettere? Alcuni server (ma non tutti) richiedono che gli script siano localizzati in una particolare directory. Quindi l’URL

    http://www.server.com/scripts/ricerca

è una richiesta di esecuzione dello script denominato ricerca. Oppure, il server può essere configurato in modo che possa eseguire qualunque file con un nome particolare, per esempio con il suffisso cgi. Se il server fosse di questo tipo l’URL

    http://www.server.com/programmi/ricerca.cgi

sarebbe una richiesta di esecuzione dello script ricerca.cgi.

Perl

Perl significa Practical Extraction and Report Language ed è un linguaggio interpretato creato da Larry Wall per la piattaforma Unix. Lo scopo è quello di assistere l’utente Unix con compiti usuali probabilmente troppo pesanti per essere implementati nella shell e troppo complicati per essere programmati in C. Oltre alla piattaforme Unix Perl è stato portato su tutti i personal più comuni. Perl è il linguaggio più comune con cui si scrivono gli script CGI.

Il flusso dei dati

CGI è uno standard che regola il modo in cui server e script si accordano su come vengono chiamati gli script e come vengono passati i dati. Il ruolo del server è infatti semplicemente quello di mandare in esecuzione lo script e passargli i dati.

I dettagli delle regole CGI dipendono dal tipo di sistema operativo su cui gira il web server: Unix, Macintosh o Windows. CGI è quindi in realtà un insieme di standard, uno per ogni sistema operativo. Tutti comunque definiscono il modo in cui lo script viene avviato e come i dati vengono passati allo e dallo script.

Il primo passo è la richiesta che proviene da parte del client. Il server quindi passa la richiesta al programma CGI per l’esecuzione. I risultati (se ci sono) vengono passati al server che li trasmette al client. Infine la connessione viene chiusa. Considerando nella descrizione dell’interazione browser-server anche il CGI, il funzionamento diventa questo:

  • Il client spedisce (con le regole del protocollo HTTP) una richiesta al server sottoforma di URL. Questa richiesta comprende il tipo di servizio desiderato (per esempio HTTP, FTP, Telnet) e la locazione della risorsa. Allegata a questa richiesta ci sono i dati header forniti dal client.
  • Il server HTTP analizza la richiesta e decide cosa fare. Se la richiesta non è HTTP, viene fatta la supplenza per il servizio appropriato; per esempio se la richiesta è FTP viene trovato il file appropriato e passato al browser.
  • Se la richiesta è HTTP il server localizza il file richiesto; secondo il tipo di file il server prende una decisione su cosa fare; se il server non comprende il tipo di file lo spedisce come semplice testo
  • Un file HTML viene spedito al client; in molti casi il server non interpreta il file in nessun modo; invece il client fa la scansione dei tag HTML per interpretare il file e “renderlo” nella finestra del browser. Una eccezione a questo è server-side include (vedi oltre)
  • Se il server riconosce il file come eseguibile, oppure un programma CGI, esegue il programma, allegando l’header ricevuto dal client; i parametri di esecuzione
  • Se non ci sono dati il programma deve comunque spedire una risposta; se ci sono dati il gateway deve farli precedere con un header che il server capisce, seguito dall’output secondo le convenzioni MIME.
  • Il server legge l’output del programma CGI e prende una decisione su cosa fare sulla base dell’header (se è di tipo Location, recupera quel file o dice al client come recuperarlo, se è di tipo Content il server spedisce i dati al client, che è responsabile del loro trattamento)
  • Quando il client ha ricevuto tutti i dati la connessione viene chiusa.

Metodo di passaggio dei dati

Il client può passare dati al gateway in due modi: o con variabili di ambiente o con uno standard input.

  1. con GET l’input viene passato accodato alla fine dell’URL
  2. con POST segue l’URL come un documento
  3. se non è specificato un metodo, è utilizzato GET

Risorse online

Server Side Include
Ci sono alcuni problemi con CGI, il più grave dei quali è la velocità. Ogni volta che il server web riceve una richiesta deve eseguire lo script CGI, e ogni volta (se non è incorporato nel server) caricare l’interprete Perl. Se le richieste CGI sono numerose, l’efficienza del server può risentirne. Un modo per risolvere il problema della velocità consiste nell’incorporare nel web server stesso alcune funzioni, che altrimenti dovrebbero essere svolte dal CGI. SSI (Server Side Include) è basato su questo idea. Si tratta di inserire tag speciali nel documento HTML; questi tag vengono interpretati al volo dal web server nel momento in cui la pagina viene trasferita al browser e non da uno script CGI.
Esempio di funzionamento del tag SSi per la visualizzazione della data del server.
Normalmente un web server ha la possibilità di eseguire diversi comandi SSI. Per esempio una serie di comandi che hanno a che fare con le date e il tempo. E anche comandi che consentono di inserire del testo in un documento, o di inserire nel documento il nome del file, la data di ultima modifica e così via. Esistono anche tag per eseguire script CGI.

SSI con tag proprietari

Proseguendo nell’idea del SSI, diverse società di software hanno progettato web server con un numero molto elevato di possibili comandi SSI. Questi server consentono agli sviluppatori di utilizzare un elevato numero di risorse incorporate per rendere le loro pagine dinamiche ben oltre il limite delle possibilità offerte dal sistema operativo. ColdFusion, per esempio, offre un insieme di più di 70 tag CFML che consentono di eseguire la maggior parte dei compiti che normalmente si richiedono ad un server.

Tuttavia ogni tecnologia basata su SSI ha una seria limitazione, dovuta al fatto che gli sviluppatori sono limitati ad un numero limitato di tag: quelli offerti dal SSI tradizionale, più quelli proprietari eventualmente presenti. Cosa succede se uno sviluppatore vuole sviluppare i propri tag?

In questo caso è necessario un modo per incorporare nelle pagine HTML codice interpretato dinamicamente che può essere processato dal web server, cioè un ibrido tra CGI e SSI. Così è nato ASP.
   
Home | Commenti a Mauro Boscarol | Ultimo aggiornamento 22 dicembre 2000