Figura 237.1. Schema del collegamento fisico e ideale tra le varie parti di una connessione HTTP-CGI.
|
|
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico] [volume] [parte]
In precedenza, nei capitoli 233, 234 e 235, è stato descritto il servizio HTTP, la configurazione di Apache, di Boa e l'utilizzo di qualche programma cliente in grado di accedere a tale servizio. In questo capitolo si intende vedere in che modo si può organizzare il proprio servente HTTP in modo da renderlo interattivo attraverso l'uso dei programmi CGI.
HTTP (Hypertext transfer protocol) è un protocollo cliente-servente progettato per gestire documenti ipertestuali e per permettere l'interazione con programmi, detti gateway, attraverso le specifiche CGI (Common gateway interface).
L'interfaccia CGI permette quindi di realizzare programmi che interagiscono con gli utenti attraverso il protocollo HTTP. La figura 237.1 illustra il meccanismo.
|
Figura 237.1. Schema del collegamento fisico e ideale tra le varie parti di una connessione HTTP-CGI.
|
I programmi gateway, detti anche cgi-bin o più semplicemente CGI, possono essere realizzati con qualunque linguaggio, purché siano in grado di interagire attraverso le specifiche del protocollo CGI.
Vale la pena di richiamare brevemente alcuni concetti riferiti agli URI per ciò che riguarda in particolare la gestione interattiva che si vuole descrivere in questo capitolo (si veda eventualmente la sezione 353). Il formato di un URI potrebbe essere definito secondo lo schema seguente:
protocollo indirizzo_della_risorsa[dati_aggiuntivi] |
Alcuni tipi di protocolli sono in grado di gestire dei dati aggiuntivi in coda all'indirizzo della risorsa. Nel caso del protocollo HTTP combinato con CGI, può trattarsi di richieste o di percorsi aggiuntivi.
Quando un URI comprende anche una stringa di richiesta (query), questa viene distinta dall'indirizzo della risorsa attraverso un punto interrogativo.(1)
protocollo indirizzo_della_risorsa?[richiesta] |
L'utilizzo di una stringa di richiesta presume che la risorsa sia un programma in grado di utilizzare l'informazione contenuta in tale stringa. Segue un esempio banale di un URI contenente una richiesta:
http://www.brot.dg/cgi-bin/saluti.pl?buongiorno
Quando l'indirizzo della risorsa di un URI fa riferimento a un programma, questo può ricevere un'informazione aggiuntiva legata a un file o a una directory particolare. Si ottiene questo aggiungendo l'indicazione del percorso che identifica questo file o questa directory.
protocollo indirizzo_della_risorsa[percorso_aggiuntivo] |
Segue un esempio banale di un URI, completo dell'indicazione di un percorso:
http://www.brot.dg/cgi-bin/elabora.pl/archivio.doc
Quando un simbolo di quelli non utilizzabili deve essere indicato ugualmente da qualche parte dell'URI, facendogli perdere il significato speciale che questo potrebbe avere altrimenti, si può convertire utilizzando la notazione %hh. La sigla hh rappresenta una coppia di cifre esadecimali. A questa regola fa eccezione lo spazio che viene codificato normalmente con il segno +, ma non in tutte le occasioni.
Generalmente, per gli indirizzi URI normali non c'è la necessità di preoccuparsi di questo problema, quindi, l'utilizzo di simboli particolari riguarda prettamente la costruzione delle richieste, come viene mostrato meglio in seguito.
La tabella 237.2 mostra l'elenco di alcune corrispondenze tra simboli particolari e la codifica alternativa utilizzabile negli URI.
|
Tabella 237.2. Alcune corrispondenze tra simboli particolari e codifica alternativa utilizzabile negli URI.
|
Il servente HTTP mostra ai programmi clienti solo una parte dei dati contenuti all'interno del proprio sistema, attraverso una sorta di astrazione; per esempio, http://www.brot.dg/ciao.html non è il file ciao.html che si trova nella directory radice del file system del nodo www.brot.dg.
L'organizzazione e l'accessibilità dei dati attraverso il protocollo HTTP può essere gestita in vario modo. Apache e Boa utilizzano per questo, le direttive seguenti.
DocumentRoot directory_root_html |
Rappresenta la directory da cui si possono diramare i documenti HTML. Se per esempio si trattasse della riga seguente
|
e un cliente volesse accedere al documento http://www.brot.dg/ciao.html, il file restituito effettivamente sarebbe /home/httpd/html/ciao.html.
Alias directory_fasulla directory_reale |
Questo tipo di direttiva, che può essere ripetuta, permette di definire delle directory in posizioni diverse da quelle reali. La directory fasulla fa riferimento a una directory indicata nell'indirizzo richiesto e quella reale indica la directory effettiva nel file system. Per esempio,
|
fa in modo che l'indirizzo http://www.brot.dg/icons/ faccia in realtà riferimento alla directory /home/httpd/icons/ e non alla directory icons/ discendente da document root.
ScriptAlias directory_fasulla directory_reale |
Funziona come la direttiva Alias, ma si riferisce ai programmi CGI. Per esempio,
|
fa in modo che l'indirizzo http://www.brot.dg/cgi-bin/ faccia in realtà riferimento alla directory /home/httpd/cgi-bin/ e non alla directory /cgi-bin/ discendente da document root.
Il funzionamento del protocollo HTTP è molto semplice. L'utilizzo di un servizio HTTP si compone di una serie di transazioni, ognuna delle quali si articola in queste fasi:
apertura della connessione;
chiusura della connessione.
In questo modo, il programma servente non deve tenere traccia delle transazioni che iniziano e finiscono ogni volta che un utente compie un'azione attraverso il suo programma cliente.
La richiesta inviata dal programma cliente deve contenere il metodo (i più comuni sono GET e POST), l'indicazione della risorsa cui si vuole accedere, la versione del protocollo ed eventualmente l'indicazione dei tipi di dati che possono essere gestiti dal programma cliente (si parla in questi casi di tipi MIME). Naturalmente sono possibili richieste più ricche di informazioni.
|
Tabella 237.6. Alcuni metodi di comunicazione per le richieste di un programma cliente. |
La risposta del servente HTTP è costituita da un'intestazione che, tra le altre cose, specifica il modo in cui l'informazione allegata deve essere interpretata. È importante comprendere subito che l'intestazione viene staccata dall'inizio dell'informazione allegata attraverso un riga vuota, composta dalla sequenza <CR><LF>.
Per comprendere in pratica il funzionamento di una connessione HTTP, si può utilizzare il programma telnet al posto di un navigatore normale. Si suppone di poter accedere al nodo www.brot.dg nel quale è stato installato Apache con successo. Dal servente viene prelevato il file index.html che si trova all'interno della directory document root.
$ telnet www.brot.dg http[Invio]
telnet risponde e si mette in attesa di ricevere il messaggio da inviare al servente.
|
Si deve iniziare a scrivere, cominciando con una riga contenente il metodo, la risorsa e la versione del protocollo, continuando con una riga contenente le possibilità di visualizzazione del cliente (i tipi MIME).
GET /index.html HTTP/1.0[Invio]
Accept: text/html[Invio]
[Invio]
Appena si invia una riga vuota, il servente intende che la richiesta è terminata e risponde.
|
Come già accennato, il messaggio restituito dal servente è composto da un'intestazione in cui l'informazione più importante è il tipo di messaggio allegato, cioè in questo caso Content-Type: text/html, seguita da una riga vuota e quindi dall'oggetto richiesto, cioè il file index.html.
Al termine della ricezione dell'oggetto richiesto, la connessione ha termine. Lo si può osservare dal messaggio dato da telnet: Connection closed by foreign host.
Il lavoro di un programma cliente è tutto qui: inviare richieste al servente HTTP, ricevere le risposte e gestire i dati, possibilmente visualizzandoli o mettendo comunque l'utente in grado di fruirne.
MIME è una codifica standard per definire il trasferimento di documenti multimediali attraverso la rete. L'acronimo sta per Multipurpose Internet mail extentions e la sua origine è appunto legata ai trasferimenti di dati allegati ai messaggi di posta, come il nome lascia intendere.
Il protocollo HTTP utilizza lo stesso standard e con questo il programma servente informa il programma cliente del tipo di oggetto che gli viene inviato. Nello stesso modo, il programma cliente, all'atto della richiesta di una risorsa, informa il servente dei tipi MIME che è in grado di gestire.
Il servente HTTP, per poter comunicare il tipo MIME al cliente, deve avere un modo per riconoscere la natura degli oggetti che costituiscono le risorse accessibili. Questo modo è dato dall'estensione, per cui, la stessa scelta dell'estensione per i file accessibili attraverso il protocollo HTTP è praticamente obbligatoria, ovvero, dipende dalla configurazione dei tipi MIME.
|
Tabella 237.9. Alcuni tipi MIME con le possibili estensioni. |
Come si è visto dagli esempi mostrati precedentemente, la richiesta fatta dal programma cliente è composta da una prima riga in cui si dichiara il tipo, la risorsa desiderata e la versione del protocollo.
|
Di seguito vengono indicati una serie di campi, più o meno facoltativi. Questi campi sono costituiti da un nome seguito da due punti (:), da uno spazio e dall'informazione che gli si vuole abbinare.
Una o più righe contenenti un campo Accept possono essere incluse per indicare i tipi MIME che il cliente è in grado di gestire (cioè di ricevere). Se non viene indicato alcun campo Accept, si intende che siano accettati almeno i tipi text/plain e text/html.
I tipi MIME sono organizzati attraverso due parole chiave separate da una barra obliqua. In pratica si distingue un tipo e un sottotipo MIME. È possibile indicare un gruppo di tipi MIME mettendo un asterisco al posto di una o di entrambe le parole chiave, in modo da selezionare tutto il gruppo relativo. Per esempio,
|
rappresenta tutti i tipi MIME;
|
rappresenta tutti i sottotipi MIME che appartengono al tipo text; mentre
|
rappresenta un tipo e un sottotipo MIME particolare.
Il campo User-Agent permette di informare il servente sul nome e sulla versione dell'applicativo particolare che svolge la funzione di cliente. Per convenzione, il nome di questo è seguito da una barra obliqua e dal numero della versione. Tutto quello che dovesse seguire sono solo informazioni addizionali per le quali non è stabilita una forma precisa. Per esempio, nel caso di Netscape, si potrebbe avere un'indicazione del tipo seguente:
|
La risposta del servente HTTP a una richiesta del programma cliente si compone di un'intestazione seguita eventualmente da un allegato, che costituisce la risorsa a cui il cliente voleva accedere. L'intestazione è separata dall'allegato da una riga vuota.
La prima riga è costituita dal codice di stato della risposta. Nella migliore delle ipotesi dovrebbe presentarsi come nell'esempio seguente:
|
Il resto dell'intestazione è composto da campi, simili a quelli utilizzati per le richieste dei programmi clienti:
|
Tabella 237.16. Alcuni codici di stato utilizzati più frequentemente. |
Il campo Allow viene utilizzato dal programma servente per informare il programma cliente dei metodi che possono essere utilizzati. Viene restituita tale informazione quando il cliente tenta di utilizzare un metodo di richiesta che il servente non è in grado di gestire. Segue un esempio.
|
Il campo Content-Length indica al programma cliente la dimensione (in byte) dell'allegato. Se viene utilizzato il metodo HEAD, con cui non viene restituito alcun allegato, permette di conoscere in anticipo la dimensione della risorsa.
|
Il campo Content-Type indica al programma cliente il tipo MIME a cui appartiene la risorsa (allegata o meno). Segue l'esempio più comune.
|
Il tipo di comunicazione che avviene tra programma cliente e programma servente, descritta nelle sezioni precedenti, è nascosta all'utente, il quale agisce attraverso la richiesta e l'invio di documenti HTML.
Si distinguono tre tipi di definizioni da inserire all'interno di documenti HTML che permettono all'utente di inserire dati (nel senso di input):
elemento ISINDEX;
attributo ISMAP delle immagini;
elementi FORM.
Quando un documento HTML contiene un elemento ISINDEX, il programma cliente fa apparire, in corrispondenza di questo, una richiesta di inserimento di un testo. La figura 237.20 mostra ciò che potrebbe apparire con un navigatore comune.
|
Figura 237.20. L'effetto della presenza di un elemento ISINDEX all'interno di un documento HTML.
|
Si tratta di una forma antiquata di interazione tra l'utente e il servizio HTTP, ma tuttora utile per comprendere i meccanismi più complessi che di fatto vengono utilizzati.
|
Si tratta di un elemento HTML obsoleto, destinato a scomparire dal DTD relativo. |
L'utente inserisce quello che vuole all'interno del campo che gli viene messo a disposizione e quando lo sottopone (di solito si tratta di premere il tasto [Invio]), il programma cliente (cioè il navigatore) converte i caratteri che necessitano di conversione, quindi invia una richiesta GET per lo stesso documento, seguito da una stringa di richiesta (preceduta dal solito punto interrogativo) ottenuta da quanto l'utente ha inserito.
Un elemento di riferimento a un file di immagine può contenere l'attributo ISMAP: <IMG SRC="..." ISMAP="ismap">. Se l'elemento dell'immagine è contenuto a sua volta in un riferimento a una risorsa, attraverso l'uso del mouse, facendo clic in una posizione qualunque dell'immagine che appare, si inviano le coordinate relative all'indirizzo indicato.
L'esempio seguente mostra il riferimento a un'immagine, racchiuso all'interno di un riferimento a un programma CGI in grado di gestire le coordinate.
|
Facendo un clic sull'immagine punta.gif mostrata dal programma cliente all'utente, vengono inviate le coordinate attraverso una richiesta GET all'indirizzo della risorsa coordinate.pl. Questo indirizzo risulta essere seguito da una stringa di richiesta (preceduta dal punto interrogativo) composta da due numeri interi, staccati da una virgola, che rappresentano rispettivamente le coordinate x e y.
I moduli ottenuti con gli elementi FORM nei documenti HTML, sono il modo più complesso e completo per permettere a un utente di interagire con un servizio. A differenza di quanto visto in precedenza, si consente l'inserimento di molte informazioni che poi vengono trasmesse nella forma nome=valore. I dati inseriti attraverso gli elementi FORM possono essere trasmessi con una richiesta GET oppure POST, attraverso l'indicazione opportuna all'interno dello stesso documento HTML che contiene il modulo.
La descrizione di questi elementi FORM viene fatta più avanti, dopo gli esempi che servono a mostrare i meccanismi elementari di comunicazione dati relativi a ISINDEX e ISMAP.
I programmi gateway, o CGI, vengono visti dai clienti come delle risorse normali. Alla chiamata, tali programmi restituiscono, attraverso il servente, un documento HTML.
I programmi gateway generano questo output e lo emettono attraverso lo standard output, che viene intercettato dal servente, che a sua volta lo completa inizialmente del codice di stato.
In pratica, un programma del genere riceve input in qualche modo attraverso il servente, che a sua volta ha ricevuto una richiesta da un cliente, quindi restituisce un documento HTML preceduto da un'intestazione, ma senza la riga di stato.
Un programma CGI banale, potrebbe essere quello che restituisce semplicemente un messaggio formattato in HTML, ogni volta che viene eseguito.
|
Supponendo di avere chiamato questo programma cgi-banale.sh, che sia stato reso eseguibile e che, nel caso di Apache o di Boa, si trovi nella directory definita attraverso la direttiva ScriptAlias come /cgi-bin/, vi si può accedere aprendo l'URI http://nodo/cgi-bin/cgi-banale.sh. Se si fa una prova con il proprio elaboratore, che funge simultaneamente da nodo cliente e da nodo servente, si potrebbe utilizzare l'URI http://localhost/cgi-bin/cgi-banale.sh.
|
Figura 237.23. Risultato per l'utente della richiesta di accedere all'URI che punta allo script elementare (cgi-banale.sh) che produce solo un output semplice senza interpretare alcun input.
|
Nelle sezioni precedenti è stato mostrato in particolare il tipo di comunicazione che si instaura tra il programma cliente e il servente, mentre la comunicazione tra il servente e il programma gateway no.
Quando un cliente invia una richiesta di accedere a una risorsa che viene riconosciuta essere un programma gateway, il servente esegue questo programma e il suo standard output viene inviato in risposta al cliente, con l'aggiunta del codice di risultato iniziale: la preparazione del resto dell'intestazione è a carico del programma gateway.
Quando il servente esegue il programma gli può inviare alcuni dati: in forma di argomenti della riga di comando, utilizzando le variabili di ambiente e anche attraverso lo standard input. Dipende dalla modalità della richiesta fatta dal cliente il modo con cui il programma gateway riceve i dati dal servente.
È sufficiente realizzare uno script in grado di restituire tutti i dati che vengono forniti dal servente al programma gateway per comprendere il meccanismo.
|
|
Figura 237.25. Richiamando lo script cgi-test.sh attraverso un URI, senza l'indicazione di alcuna stringa di richiesta, si ottiene lo stato delle variabili di ambiente fornite allo script stesso.
|
Eventualmente si può realizzare un altro programma, in Perl, che compie praticamente le stesse operazioni, ma in modo più preciso.
|
Le forme più semplici attraverso cui un utente può dare un input a un programma gateway sono: i percorsi aggiuntivi, i marcatori ISINDEX e gli attributi ISMAP delle immagini.
Il percorso aggiuntivo, tra tutti, è il concetto più semplice, anche se raramente se ne incontra l'utilizzo. Si ottiene richiedendo un URI che punta a un programma gateway seguito, immediatamente e senza separazioni addizionali, da un percorso che indichi un file o una directory. Il programma gateway riceve questa informazione all'interno di variabili di ambiente.
Per verificarlo basta usare uno dei due script mostrati nella sezione precedente. Si può anche tentare di raggiungere un percorso che non esiste. Supponendo di indicare l'URI http://nodo/cgi-bin/cgi-test.sh/ciao/come/stai, lo script riceve (e mostra) la variabile di ambiente PATH_INFO con il valore /ciao/come/stai, mentre la variabile PATH_TRANSLATED contiene la (presunta) traduzione di quel percorso in un percorso reale, corrispondente probabilmente a document_root/ciao/come/stai. Sta quindi al programma (o allo script) gateway sapere cosa farsene di questa informazione.
Un'altra forma di input elementare, ormai in disuso, è l'elemento ISINDEX. Per comprendere di cosa si tratta basta modificare leggermente uno dei due script di analisi preparati nella sezione precedente. Viene mostrato il caso dello script di shell.
|
In corrispondenza dell'elemento ISINDEX, il programma cliente mette a disposizione un campo modificabile dall'utente, come appare nella figura 237.20 già mostrata in precedenza. Per esempio, si può provare a scrivere la frase uno due tre, premere [Invio] e vedere cosa succede (si immagina che lo script si chiami cgi-test2.sh).
Gli spazi vengono trasformati con il segno + e il testo corrispondente viene accodato all'URI (dopo l'aggiunta di un punto interrogativo): http://nodo/cgi-bin/cgi-test2.sh?uno+due+tre. Per questo URI, completato della stringa codificata, il cliente esegue una richiesta GET.
Il programma gateway riceve questa informazione attraverso la variabile di ambiente QUERY_STRING, contenente uno+due+tre, e anche attraverso gli argomenti della riga di comando, dove le tre parole corrispondono ad altrettanti argomenti separati.
L'ultimo, tra i tipi di input descritti in questa sezione, è quello ottenuto attraverso l'attributo ISMAP delle immagini. Per comprendere di cosa si tratta, basta modificare leggermente uno dei due script di analisi preparati nella sezione precedente. Viene mostrato il caso dello script di shell.
|
Per vedere funzionare questo esempio occorre anche un file di immagine, test.jpg, da collocare nella directory di inizio dei documenti HTML, ovvero document root.
Basta fare un clic con il mouse, da qualche parte sull'immagine, perché il programma cliente calcoli le coordinate corrispondenti, espresse in punti grafici (pixel), attaccandole in coda all'URI. Per esempio, l'URI http://nodo/cgi-bin/cgi-test3.sh?10,15 rappresenta un clic eseguito nel punto x=10, y=15.
Il programma (lo script) cgi-test3.sh riceve questa informazione attraverso la riga di comando e anche attraverso il contenuto della variabile QUERY_STRING.
È già stato introdotto l'argomento relativo agli elementi FORM. Fino a questo punto sono state presentate solo tecniche elementari per permettere l'interazione tra l'utente e un servizio HTTP. In particolare, l'elemento ISINDEX è praticamente del tutto inutilizzato. La vera interazione avviene con modelli HTML complessi, basati su elementi FORM. Un particolare da osservare, prima di affrontare questo nuovo argomento, è il fatto che tutti i tipi di interazione visti finora sono basati su richieste che utilizzano il metodo GET.
Gli elementi FORM servono a generare dei moduli di inserimento dati per l'utente. L'input ottenuto in questo modo viene assemblato in coppie nome=valore. È poi compito del programma gateway disassemblare e interpretare tali informazioni.
I moduli degli elementi FORM vengono generati dal programma cliente (cioè dal navigatore) in base alle direttive incontrate all'interno di un documento HTML. Ciò significa che l'apparenza di questi moduli può essere diversa a seconda del programma cliente utilizzato e del sistema operativo.
Il documento HTML contenente moduli di questo tipo, ovviamente, può essere stato predisposto nel servente come file normale, oppure può essere generato dinamicamente da un programma gateway.
Un modulo di questo tipo viene dichiarato e delimitato dall'elemento FORM, all'interno di un documento HTML:
<FORM ...>
...
...
...
</FORM>
|
Un documento HTML può contenere più elementi FORM, purché non siano annidati. L'elemento FORM può contenere degli attributi che ne definiscono il comportamento generale (ovviamente gli attributi si inseriscono nel marcatore di apertura), mentre all'interno della zona definita dall'elemento FORM si possono inserire altri elementi di vario genere, il cui scopo è quello di permettere all'utente un tipo particolare di interazione.
L'attributo ACTION dell'elemento FORM specifica l'URI a cui inviare i dati inseriti attraverso il modulo. Deve trattarsi evidentemente dell'indirizzo di un programma gateway in grado di gestirli. Intuitivamente si comprende che questo attributo non può mancare. L'esempio seguente mostra in che modo si possa inserire questo attributo.
|
L'attributo METHOD dell'elemento FORM specifica il metodo della richiesta che deve essere fatta dal cliente. Utilizzando un elemento FORM sono disponibili due tipi: GET e POST. L'esempio seguente mostra una situazione in cui si definisce l'utilizzo del metodo POST.
|
All'interno dell'ambiente delineato dall'elemento FORM, cioè della zona delimitata dai marcatori <FORM> e </FORM>, si può collocare sia testo normale, sia elementi specifici di questo ambiente. È stato ripetuto più volte che i dati inseriti attraverso questi elementi vengono assemblati in coppie nome=valore. Quello che manca da sapere è che tali coppie vengono unite successivamente attraverso il simbolo e-commerciale (&). Gli esempi proposti più avanti mostrano meglio questo comportamento.
Esistono pochi tipi di elementi atti a permettere l'input all'interno dell'ambiente dell'elemento FORM. Questi cambiano il loro comportamento e l'apparenza a seconda degli attributi che gli vengono indicati. Il tipo di elemento più comune è INPUT:
<INPUT NAME=... TYPE=... ...> |
Tutti gli elementi che permettono l'input hanno in comune l'attributo NAME che è obbligatorio. Le sezioni seguenti mostrano alcuni degli elementi utilizzabili in un modulo.
Si tratta di un elemento che consente l'inserimento di testo normale su una sola riga. Questo elemento non richiede l'indicazione del tipo, attraverso l'attributo TYPE.
|
L'esempio seguente visualizza un campo di 20 caratteri all'interno del quale l'utente deve scrivere il nome di un colore. Nel campo appare già la scritta giallo che può essere modificata o cancellata a piacimento.
|
Si tratta di un elemento che consente la scrittura di testo normale nascondendone l'inserimento, come avviene di solito quando si introducono le parole d'ordine.
Dal momento che, a parte l'oscuramento dell'input, il funzionamento è uguale a quello dei campi di input normali, si possono utilizzare anche gli stessi tipi di attributi.
L'esempio seguente visualizza un campo di 20 caratteri all'interno del quale l'utente deve inserire la parola d'ordine richiesta.
|
Si tratta di un elemento che visualizza una casellina da barrare (casella di spunta). Queste caselline appaiono senza selezione in modo predefinito, a meno che venga utilizzato l'attributo CHECKED. Se la casellina risulta selezionata, viene generata la coppia nome=valore corrispondente, altrimenti no.
|
L'esempio seguente visualizza una casellina già barrata inizialmente. Se viene lasciata così, selezionata, questo elemento genera la coppia propaganda=SI.
|
Si tratta di un elemento che permette la selezione esclusiva di un pulsante all'interno di un gruppo. In pratica, selezionandone uno, si deselezionano gli altri.
Rispetto agli elementi visti in precedenza, questo richiede la presenza di più elementi dello stesso tipo, altrimenti non ci sarebbe da scegliere. Il collegamento che stabilisce che i pulsanti appartengono allo stesso gruppo viene definito dal nome che rimane uguale.
|
L'esempio seguente visualizza tre pulsanti, di cui il primo già selezionato, per la scelta di un tipo di contenitore. I tre bottoni sono collegati insieme perché hanno lo stesso valore associato all'attributo NAME.
|
Questo tipo di elemento visualizza un tasto contenente un'etichetta; selezionandolo si ottiene l'invio dei dati contenuti nel modulo in cui si trova. L'etichetta che appare sul pulsante in modo predefinito dipende dal cliente e potrebbe trattarsi di Submit o qualcosa del genere.
Questo elemento è diverso dagli altri in quanto non è previsto l'uso dell'attributo NAME. Infatti non viene generato alcun dato da questo, ma solo l'invio dei dati contenuti nell'elemento FORM.
L'esempio seguente visualizza un tasto sul quale appare la scritta Invia la richiesta. Selezionandolo viene inviato il contenuto del modulo.
|
Si tratta di una sorta di tasto di invio (submit) che in più aggiunge le coordinate in cui si trova il puntatore nel momento del clic. In un certo senso assomiglia anche agli elementi con l'attributo ISMAP descritto prima di affrontare gli elementi FORM.
|
L'esempio seguente visualizza l'immagine immagine.jpg e se viene fatto un clic con il puntatore del mouse sulla sua superficie, vengono inviati i dati del modulo, assieme anche alle coordinate relative all'immagine.
|
Questo tipo di elemento, a prima vista, non ha alcun senso: permette di inserire dei campi nascosti, cosa che serve a generare una coppia nome=valore fissa.
All'inizio di questo capitolo è già stato chiarito, che il protocollo HTTP non ha alcun controllo sullo stato delle transazioni, o meglio, ogni richiesta si conclude con una risposta. In questo modo, è compito del programma gateway mantenere il filo delle operazioni che si stanno svolgendo. Una delle tecniche con cui è possibile ottenere questo risultato è quella di restituire un modello contenente le informazioni già inserite nelle fasi precedenti.
Ci sono anche altre situazioni in cui i dati nascosti e predefiniti sono utili, ma per il momento è sufficiente tenere a mente che esiste la possibilità.
|
L'esempio seguente fa in modo che il modulo contenga anche la coppia nominativo=Tizio che altrimenti, si suppone, renderebbe inutilizzabili gli altri dati inseriti dall'utente.
|
Questo elemento permette all'utente di inserire un testo su più righe. L'interruzione di riga, in questo caso, è fatta utilizzando la sequenza <CR><LF>. Questo particolare va tenuto presente in fase di programmazione, dal momento che gli ambienti Unix (in particolare i sistemi GNU) utilizzano l'interruzione di riga rappresentata con il solo carattere <LF>.
|
L'esempio seguente visualizza un'area per l'inserimento di testo su più righe. L'area visibile ha la dimensione di sette righe per 40 colonne e contiene già il testo CIAO! che può essere modificato o sostituito con qualcos'altro.
|
L'elemento SELECT delimita un ambiente attraverso cui si definiscono una serie di scelte possibili, che normalmente appaiono in forma di menù a scomparsa. Per questo, oltre a SELECT si devono utilizzare una serie di elementi OPTION con cui si indicano tali scelte possibili. Va tenuto in considerazione che l'attributo NAME viene indicato nell'elemento SELECT (nel marcatore di apertura).
|
|
L'esempio seguente presenta un menù di scelta a scomparsa per la selezione di un colore che poi viene convertito in un codice numerico corrispondente. Il nero, corrispondente allo zero, risulta predefinito.
|
Esistono differenze nel modo con cui i programmi gateway ricevono le informazioni dal servente. Il modo fondamentale attraverso cui ciò viene controllato dal programma cliente è la scelta del metodo della richiesta: GET o POST. Fino a questo punto sono stati visti esempi che utilizzano esclusivamente il metodo GET.
Quando un programma cliente invia una richiesta utilizzando il metodo GET appende all'URI tutte le informazioni aggiuntive necessarie. In pratica, l'URI stesso comprende l'informazione. Per convenzione, la richiesta è distinta dalla parte dell'URI che identifica la risorsa attraverso un punto interrogativo, come nell'esempio seguente, dove la parola ciao è l'informazione aggiuntiva che rappresenta l'input per il programma cgi-test.sh:
http://www.brot.dg/cgi-bin/cgi-test.sh?ciao
È già stato descritto in che modo debbano essere codificati i caratteri riservati, per fare sì che quanto ottenuto sia sempre un URI valido.
Per convenzione, se il testo della richiesta che segue il punto interrogativo contiene il simbolo = (senza alcuna trasformazione), si intende che si tratti di una richiesta proveniente da un modulo HTML (elemento FORM), altrimenti da un semplice elemento ISINDEX oppure da un'immagine con l'attributo ISMAP.
In pratica, se sembra una richiesta ISINDEX perché non appare il segno di assegnamento (=) non protetto in alcun modo, il programma gateway riceve la stringa di richiesta attraverso gli argomenti della riga di comando e anche la variabile di ambiente QUERY_STRING, altrimenti li riceve solo attraverso la variabile QUERY_STRING.
In questa situazione, in presenza di una richiesta GET, il programma gateway può concentrarsi nell'analisi della sola variabile QUERY_STRING.
http://www.brot.dg/cgi-bin/cgi-test.sh?nome=Pinco&cognome=Pallino&sesso=M
L'URI mostrato sopra rappresenta una richiesta proveniente (presumibilmente) da un modulo HTML (elemento FORM), per la presenza dei simboli di assegnamento. Come si può osservare, ogni coppia nome=valore è collegata alla successiva attraverso il simbolo e-commerciale (&).
Il metodo GET, in quanto aggiunge all'URI la stringa di richiesta, permette all'utente di controllare e di memorizzare il flusso di dati, per esempio attraverso un segnalibro (bookmark). In pratica, con la semplice memorizzazione dell'URI, l'utente può riprendere un'operazione di inserimento di dati, senza dover ricominciare tutto dall'inizio.
Lo svantaggio nell'utilizzo di tale metodo sta nel fatto che esiste un limite alla dimensione degli URI e di conseguenza anche alla quantità di dati che gli si possono accodare.
Il metodo POST è stato progettato per porre rimedio ai limiti dell'altro metodo. Con questo, i dati dei moduli HTML (elementi FORM) vengono inviati in modo separato dall'URI, mentre il gateway li riceve dal programma servente attraverso lo standard input. Sotto questo aspetto, il metodo POST è generalmente preferibile.(2)
È stato fatto riferimento più volte alle variabili di ambiente e al loro ruolo nel sistema di comunicazione tra il servente e il programma gateway. Segue l'elenco di quelle più importanti.
|
Informazioni sulla connessione cliente-servente.
|
|
Informazioni passate dal cliente al servente.
|
Quando il cliente invia una richiesta al servente, prepara un'intestazione all'interno della quale possono essere inseriti diversi campi. Il contenuto di questi campi viene tradotto in altrettante variabili di ambiente il cui nome inizia per HTTP_ seguito dal nome del campo stesso. In particolare, i caratteri minuscoli sono convertiti in maiuscoli e i trattini normali sono sostituiti dal trattino basso. Segue la descrizione di alcune di queste variabili.
|
Informazioni addizionali dal cliente.
|
Prima di iniziare a pensare a dei programmi gateway concludenti, conviene verificare quanto scritto attraverso i programmi di analisi mostrati in precedenza: cgi-test.sh oppure cgi-test.pl. Negli esempi viene mostrato sempre il primo dei due, anche se il migliore per queste cose sarebbe il secondo.
Si può realizzare una pagina HTML contenente dei moduli (elementi FORM), come nell'esempio seguente, che si rifà ad altri esempi visti in precedenza.(3)
|
Come si può vedere sono presenti due elementi FORM indipendenti: il primo utilizza il metodo GET, il secondo invece il metodo POST. Entrambi gli elementi FORM richiamano il programma gateway /cgi-bin/cgi-test.sh.
|
Figura 237.54. Richiamando il file HTML dell'esempio,
|
Si può già provare così, anche senza modificare alcunché. Se si invia la richiesta attraverso il modulo che utilizza il metodo GET, si può osservare che la richiesta va a fare parte dell'URI del programma gateway; di conseguenza viene inserita nella variabile QUERY_STRING. Altrimenti, con il metodo POST la richiesta si ottiene solo dallo standard input. In entrambi i casi, dovrebbe risultare codificata nello stesso modo (codifica URI).
|
Si può osservare in particolare la presenza della coppia nominativo=Tizio, inserita a titolo di esempio come campo nascosto e costante. Se invece di inviare il modulo attraverso la selezione del pulsante (submit) si utilizza l'immagine, si ottiene una stringa simile a quella seguente:
|
A questo punto, il lettore dovrebbe provare per conto proprio a compilare i campi, a modificare le selezioni, in modo da prendere dimestichezza con l'effetto generato dagli elementi FORM.
W3C, World Wide Web Consortium
Appunti di informatica libera 2006.07.01 --- Copyright © 2000-2006 Daniele Giacomini -- <daniele (ad) swlibero·org>
1) L'uso del punto interrogativo rende la cosa intuitiva: la richiesta viene fatta attraverso un'interrogazione.
2) I motori di ricerca utilizzano normalmente il metodo GET, che consente di trasmettere l'interrogazione richiesta nell'indirizzo usato, che viene memorizzato dai serventi HTTP come referente. Questa è una situazione pratica in cui il metodo POST non sarebbe adatto.
3) L'esempio del file form-test.html viene proposto secondo lo standard HTML 4.01, perché alcuni attributi usati sono incompatibili con ISO-HTML.
Dovrebbe essere possibile fare riferimento a questa pagina anche con il nome servente_http_cgi.htm
[successivo] [precedente] [inizio] [fine] [indice generale] [indice ridotto] [translators] [docinfo] [indice analitico]
