Newsgroup: it.comp.aiuto
Titolo: QUESITO PER SOLI ESPERTI...

Visto che sei un esperto,preparati al quesito fumapalle del secolo!
Cosa vuoi trovare in questo quesito?
.......come funziona un cgi ?
grazie...

....
Tutte queste cose, piu' o meno, gia le sapevo. Grazie comunque. Ma ti 
vorrei porre un quesito.
Ammettiamo che un link di un documento HTML punti ad un programma
(ad esempio pippo.out) residente in una certa dir di un certo server
www.
Ora, sotto l'ipotesi che non ci sia un passaggio di parametri, se il 
mio programmino, magari fatto in C, esegue una 
....
printf("\nPippo\n");
...
quando il server esegue il programma (...se lo esegue) dove va a 
finire quel Pippo ?? Nel browser ??
Grazie.

 writes:


Hai presente intanto come funziona una normale transazione HTML?
Se l'utente richiede una URL 
http://www.pippo.com/file.html
, il
suo browser (user agent) apre una connessione in HyperText Transfer
Protocol con il servente a 
www.pippo.com
, e gli manda una richiesta di
"GET /file.html HTTP/1.0" seguita dai vari parametri relativi a chi
sia il richiedente, quale sia lo user-agent stesso, e che tipi MIME
di dati sia disposto ad accettare, terminandola con una riga vuota
(questa richiesta segue i normali standard degli header RFC 822).
Il servente, se trova il documento richiesto, replica con una breve
testata che inizia con "HTTP/1.0 200 OK" e comprende alcune altre
informazioni sul documento (compreso il suo tipo di contenuto a
standard MIME), terminandolo con una riga vuota (anche questo header
segue gli standard RFC 822), poi il documento stesso.
Ora, l'URL, invece che un documento, puo` identificare uno "script",
cioe` un programma che risiede sul server.  Questo puo` non essere
immediatamente evidente dall'URL stessa, cioe` il fatto che un certo
nodo sia uno script (da eseguire) invece che un mero documento (da
recuperare) puo` dipendere da parametri di istallazione del server
che rimangono trasparenti ai clienti.  Ad esempio, un server puo`
essere istallato in modo che tutti i ``documenti'' residenti in
un certo directory (uno chiamato cgi-bin e` una popolare scelta)
vengano in realta` eseguiti come script.
In ogni caso, gli script cosi` eseguiti sono appunto quelli che
utilizzano la "Common Gateway Interface", o CGI.  Possono essere
scritti in qualsiasi linguaggio, anche se penso che il Perl sia
di gran lunga il piu` popolare.  Lo script (programma) CGI, in
pratica, genera "al volo" il ``documento'' da restituire al
cliente a fronte della sua richiesta; il server restituisce
questo risultato ne` piu` ne` meno come se fosse un documento
gia` esistente, anche se e` stato calcolato li` per li`... anche
da questo punto di vista, l'operazione puo` essere dunque resa
totalmente "trasparente".
Per fare un esempio banale, io potrei avere un "documento"
numeriprimi.html che elenca i primi mille numeri primi; se a un
certo punto decido di risparmiare spazio disco sostituendolo
con uno *script* che *calcola* i primi numeri primi, e se il
server che uso e` decentemente configurabile, posso organizzare
la cosa in modo che i clienti neppure se ne accorgano, bensi`
continuino a fare le loro richieste esattamente come quando
l'oggetto in questione era un "vero" documento html!
Il problema naturalmente e` che in questo modo non riesco a
passare al mio script CGI degli *argomenti*, ovvero degli
*input*, per cui l'utilita` del procedimento resterebbe ahime`
piuttosto circoscritta... una prima possibilita` e` quella di
codificare alcuni argomenti nell'URL stessa, come parte del
campo "nome del documento", separandoli dal nome dello script
vero e proprio con un '?' -- ma questo sarebbe solo un piccolo
aumento di flessibilita`, se gli argomenti stessi dovessero
comunque essere "hard-coded" nella stringa-URL...
E` qui che entrano in gioco le *forms* html, con i loro vari tag di
input, select, ecc, che permettono all'utente di preparare i dati di
input per lo script CGI.  Quando l'accesso a uno script CGI avviene
tramite un form, la richiesta, invece di iniziare con il verbo GET
come sopra accennato per le normali transazioni di richiesta HTTP,
usa il verbo POST, e dopo l'header contiene i vari dati ottenuti
dalla form con la sintassi "nome=valore" per ogni campo dati (si
possono anche arrangiare le cose per usare comunque il verbo GET
con la forma che prima accennavamo, con il '?' come separatore;
di abitudine, si limita la forma GET a insiemi di dati non troppo
lunghi, e orientati alla "query" di un data base piuttosto che
alla sua modifica o aggiornamento).
Il server passa comunque questi dati al CGI script come input
(alcuni valori di controllo nell'"environment", il grosso come
standard input), e lo script e` responsabile di controllare e
parsare questi opportunamente per poi emettere su standard output il
risultato (normalmente un documento HTML, ma puo` essere qualsiasi
MIME content-type, tipo immagini o altro).  Naturalmente esistono
librerie di funzioni che, a seconda del linguaggio che uno vuole
usare per scrivere lo script CGI, gli possono facilitare il lavoro,
ma non e` obbligatorio usarle...
Le cose sono solo apparentemente piu` complesse quando anche il
FORM e`, non un "documento" fisso, bensi` e` a sua volta generato
da un altro script CGI; questo non e` che un caso particolare di
quello che dicevamo, che *qualsiasi* (apparente) "documento"
che il tuo user-agent ottiene con una transazione di GET puo` in
realta` essere "generato al volo" da uno script CGI (senza input).
Questa informazione che ho offerto e` sostanzialmente un riassunto
(tradotto) di quanto disponibile alla URL:
 
http://kuhttp.cc.ukans.edu/info/forms/forms-intro.html
 
Info piu` dettagliate puoi trovarle a 
http://www.best.com/~hedlund/cgi-faq
,
altre ancora a 
http://www.yahoo.com/Computers/World_Wide_Web/Programming/
.
Happy Webbing...!
Alex
--
Alex Martelli, Bologna, Italia -- DISCLAIMER: these are only MY opinions...!
 __   Man has no Body distinct from his Soul...         |  William Blake
 \/   Energy is the only life, and is from the Body...  |     DID know
      Energy is Eternal Delight.                        |  where it's at...

finire quel Pippo ?? Nel browser ??
Il Pippo, preceduto e seguito da un fine-linea, va a finire nel
*documento* che il server restituisce al browser, come seconda
meta` della transazione HTTP.  A seconda del Content Type, il
browser lo interpretera` in modi diversi (ad esempio, se il
content type e` image/gif, i bit dei caratteri ascii verranno
appunto decodificati [o almeno ci si provera`!-)] a standard
GIF; se html, dipende tutto dal contesto, se quella stringa
sara` parte di una qualche tag, ad esempio).
