Capacités d'interfaçage de Perl avec Internet

Bonjour,

J'aimerais avoir un petit topo de ce qu'on peut faire en Perl en rapport
avec Internet, et de comment ça marche. J'ai compris que du côté "serveur"
on pouvait faire des scripts de traitement de formulaires, d'interfaçage
avec des bases de données...

Je dirais même plus, on peut tout faire :-)

Est ce que CGI désigne uniquement le moyen de
recevoir/émettre des données à un script Perl ?

CGI : Common Gateway Interface
C'est un protocole qui permet à un serveur web (soit un serveur http) de
transmettre des données à un programme executable par le serveur, et de
récupérer une réponse. Soit le schéma suivant :

Client <--(HTTP)--> Serveur HTTP <--(CGI)--> Programme

les flèches (ici à double sens) symbolisant les transferts et (***)
symbolisant les protocoles de communication.

dans le cas particulier de Perl, on inclue en première ligne du script le
chemin de l'interpréteur (valable pour la plus part des configurations du
serveur Apache, que ce soit sous Windows, Unix ou Linux. Sinon, dans le cas
particulier de l'environnement Windows, l'extention peut déterminer le
chemin de l'interpréteur (s'il est correctement configurer auprès de serveur
ou de l'environnement Windows)

Pour ces applications quels
sont les prérequis à l'utilisation de Perl ?

Peu de prérequis sont nécessaires pour le développement web en Perl, pour
peu qu'on connaisse déjà Perl.
Il faut savoir que le flux de sortie principal correspond à ce qui va être
envoyé par le serveur http au client, en réponse à la demande.
Et les paramètres relatifs à la configuration du serveur et la demande du
client sont tous inclus dans la variable globale %ENV (nul besoin de définir
cette varialble)
Pour une utilisation avancée, il est préférable de connaître les standards
liés au web (les en-têtes HTTP, par exemple, qui permettent de définir les
données que vous envoyez au client)
Pour une utilisation simpliée, il faut juste savoir que l'en-tête d'un
document HTML se définit au grnad-minimum par l'en-tête "Content-Type:
text/html" et vous initialiserez donc au moins votre flux de données par :

print "Content-Type: text/htmlnn";

Chaque élément de l'en-tête doit se situer sur une nouvelle ligne, et
l'en-tête est distinguée du reste du flux de données par une ligne vierge.
C'est pour cette raison que dans l'exemple ci-dessus, on a deux "n" : l'une
pour marquer la fin du paramètre, l'autre pour marquer la fin de l'en-tête.
Vous pouvez ensuite envoyer par la méthode print votre document au client,
qui considèrera alors les données comme étant un document HTML.

Par exemple j'imagine qu'il
faut impérativement un serveur web qui sert d'"interpréteur" du langage ?

Non, ce n'est pas le serveur web qui interpréète le language, mais
l'interpréteur Perl lui même. Il est uniquement nécessaire d'avoir un
serveur web standard, un interpréteur Perl et de faire connaître au serveur
web le chemin d'acces à l'interpréteur, de même que les répertoires du site
web pouvant permettre l'exécution de scripts ou exécutables (CHMOD 755,
option ExecCGI sur Apache, et d'autres manières qui dépendent des outils
utilisés)

Et du côté "client", est ce qu'on pourrait envisager par exemple de faire
un

navigateur internet rudimentaire ? C'est à dire de pouvoir récupérer via
Perl les éléments d'une page internet. Et dans ce cas aussi comment s'y
prend t-on ?

L'intérêt du protocole CGI est de pouvoir récupérer les données transmises
au moyen de formulaires situés sur les pages web affichées par le client.
Comme il a été dit précédemment, toute donnée relative soit au serveur, soit
à la requête du client se situe dans la variable %ENV. Ce qui signifie qu'en
l'explorant, vous trouverez toutes les informations dont vous pouvez
disposer.
Aussi, des développeurs ont mis à disposition des modules Perl permettant de
simplifier ces échanges, dont le plus répendu est CGI.pm.
Il n'est possible de recevoir d'informations sur les client que par le moyen
de l'URL, des cookies et des formulaires.

Merci de vos lumières.

J'espère que celà répond à vos attentes :-)


Julien

Merci pour ta réponse encore plus complète que ce que j'attendais. Il me
reste quelques zones d'ombre après cette lecture :

Il faut savoir que le flux de sortie principal correspond à ce qui va être
envoyé par le serveur http au client, en réponse à la demande.

Intéressant, ça veut dire si je comprends bien qu'il faut écrire du code
Perl qui génére "dynamiquement" du HTML.

Par exemple j'imagine qu'il
faut impérativement un serveur web qui sert d'"interpréteur" du langage
?

Non, ce n'est pas le serveur web qui interpréète le language, mais
l'interpréteur Perl lui même. Il est uniquement nécessaire d'avoir un
serveur web standard, un interpréteur Perl et de faire connaître au
serveur

web le chemin d'acces à l'interpréteur, de même que les répertoires du
site

web pouvant permettre l'exécution de scripts ou exécutables (CHMOD 755,
option ExecCGI sur Apache, et d'autres manières qui dépendent des outils
utilisés)

Donc il faut quand même que la machine qui fait le serveur web soit aussi
équipée de l'interpréteur Perl. Est ce le cas des hébergeurs grand public ?

L'intérêt du protocole CGI est de pouvoir récupérer les données transmises
au moyen de formulaires situés sur les pages web affichées par le client.

D'accord pour un fonctionnement d'exploitation de formulaires, mais
l'application qui m'intéresse serait plutôt de style "récupérer
automatiquement la liste des titres de l'actualité qui s'affichent sur la
page http://fr.news.yahoo.com/ " ou bien "récupérer l'image qui s'affiche
sur la page météo". Est ce que Perl peut m'aider à accéder au résultat
d'affichage d'une page web ou au moins à sa source ? ou est-il nécessaire de
faire appel à un langage plus adapté ?

Merci pour ta réponse encore plus complète que ce que j'attendais. Il me
reste quelques zones d'ombre après cette lecture :

Il faut savoir que le flux de sortie principal correspond à ce qui va
être

envoyé par le serveur http au client, en réponse à la demande.

Intéressant, ça veut dire si je comprends bien qu'il faut écrire du code
Perl qui génére "dynamiquement" du HTML.

Tout à fait. On peut aussi (c'est préférable) utiliser un système de
template (comme par exemple avec le module HTTP::Template). Dans ce cas, on
crée des documents HTML sur le serveur en prenant soit de réserver des zones
pour contenir des éléments dynamiques (la lecture de l'aide du module est
indispensable pour en connaître les possibilités).
Dans le script Perl, on ouvrira le fichier et on remplacera les dites zones
par le contenu dynamique, puis on fait sortir le tout. Ainsi, c'est moins
compliqué que d'intégrer le code HTML au code Perl (j'ai des souvenirs
horribles de cette méthode dans mes débuts avec Perl pour le web ;o) )

Par exemple j'imagine qu'il
faut impérativement un serveur web qui sert d'"interpréteur" du
langage

?

Non, ce n'est pas le serveur web qui interpréète le language, mais
l'interpréteur Perl lui même. Il est uniquement nécessaire d'avoir un
serveur web standard, un interpréteur Perl et de faire connaître au
serveur

web le chemin d'acces à l'interpréteur, de même que les répertoires du
site

web pouvant permettre l'exécution de scripts ou exécutables (CHMOD 755,
option ExecCGI sur Apache, et d'autres manières qui dépendent des outils
utilisés)

Donc il faut quand même que la machine qui fait le serveur web soit aussi
équipée de l'interpréteur Perl. Est ce le cas des hébergeurs grand public
?

Oui et non.
Les hébergeurs gratuits ne permettent pas l'utilisation de Perl sur leur
serveur, il y a un trop grand risque de piratage et dans ce cas, il est
impossible de pouvoir concrètement identifier la source (puisque les sites
hébergés gratuitement ne sont pas réellement sous le responsabilisé de
quiconque).
Par contre les hébergeur payants (même aux tarifs discount, bien souvent)
proposent Perl en standard. Pour faire héberger un script Perl, il faut donc
donner de sa poche, même si ce n'est pas grand chose.
Si votre but est une utilisation perosnnelle de votre site, vous pouvez
l'héberger sur votre ordinateur même.
Depuis Windows 2000, tous les suivants disposent d'un serveur web intégré
(sauf peut-être les versions Familiales). Idem pour Mac OS X et toute
distribution Unix ou Linux. Il suffit alors d'installer un interpréteur Perl
(ex ActivePerl, www.activestate.com) gratuit et après quelques ajustements
de paramètres, vous disposerez de votre serveur personnel

L'intérêt du protocole CGI est de pouvoir récupérer les données
transmises

au moyen de formulaires situés sur les pages web affichées par le
client.

D'accord pour un fonctionnement d'exploitation de formulaires, mais
l'application qui m'intéresse serait plutôt de style "récupérer
automatiquement la liste des titres de l'actualité qui s'affichent sur la
page http://fr.news.yahoo.com/ " ou bien "récupérer l'image qui s'affiche
sur la page météo". Est ce que Perl peut m'aider à accéder au résultat
d'affichage d'une page web ou au moins à sa source ? ou est-il nécessaire
de

faire appel à un langage plus adapté ?

Ce genre d'information est tout à fait récupérable. Perl est capable
d'établir des connections réseaux "tout seul". Ainsi, il existe des modules
(comme HTTP::Request) pour télécharger des données d'un serveur HTTP (mais
qui n'ont alors rien à voir avec les données du client qui consulte votre
site)


Julien

D'accord pour un fonctionnement d'exploitation de formulaires, mais
l'application qui m'intéresse serait plutôt de style "récupérer
automatiquement la liste des titres de l'actualité qui s'affichent sur
la page http://fr.news.yahoo.com/ " ou bien "récupérer l'image qui
s'affiche sur la page météo". Est ce que Perl peut m'aider à accéder au
résultat d'affichage d'une page web ou au moins à sa source ? ou est-il
nécessaire
de

faire appel à un langage plus adapté ?

Ce genre d'information est tout à fait récupérable. Perl est capable
d'établir des connections réseaux "tout seul". Ainsi, il existe des
modules (comme HTTP::Request) pour télécharger des données d'un serveur
HTTP (mais qui n'ont alors rien à voir avec les données du client qui
consulte votre site)

Ou, en plus haut niveau: WWW::Mechanize
un réel régal pour scripter un accès à un site web et en récupérer toutes
les informations dont on a besoin.

Patrick.

dans le cas particulier de Perl, on inclue en première ligne du script
le chemin de l'interpréteur (valable pour la plus part des

Si on veut être complet, ce n'est pas toujours nécessaire, par exemple
quand on fait du mod_perl :-)

Il faut savoir que le flux de sortie principal correspond à ce qui va
être envoyé par le serveur http au client, en réponse à la demande. Et
les paramètres relatifs à la configuration du serveur et la demande du
client sont tous inclus dans la variable globale %ENV (nul besoin de
définir cette varialble)
Pour une utilisation avancée, il est préférable de connaître les
standards liés au web (les en-têtes HTTP, par exemple, qui permettent de
définir les données que vous envoyez au client) Pour une utilisation
simpliée, il faut juste savoir que l'en-tête d'un document HTML se
définit au grnad-minimum par l'en-tête "Content-Type: text/html" et

Le module CGI (ou CGI::Lite) s'occupe de tous les petits détails, et donc
simplifie grandement la tache. Un script CGI en perl peut alors tenir en
5 lignes:
#!/usr/bin/perl
use CGI;
my $q=CGI->new();
print $q->header();
print "Vous avez écrit: ".$q->param('texte');

(si j'ai le droit à une 6ème ligne, j'ajoute ``use strict;'')

Par exemple j'imagine qu'il
faut impérativement un serveur web qui sert d'"interpréteur" du langage
?

Non, ce n'est pas le serveur web qui interpréète le language, mais
l'interpréteur Perl lui même. Il est uniquement nécessaire d'avoir un
serveur web standard, un interpréteur Perl et de faire connaître au

C'est tout à fait exact. Mais, encore une fois, en mod_perl,
l'interpréteur Perl est dans le serveur Web, donc parfois la séparation
entre les deux est bien infime (c'est le but de mod_perl d'ailleurs).

L'intérêt du protocole CGI est de pouvoir récupérer les données
transmises au moyen de formulaires situés sur les pages web affichées
par le client. Comme il a été dit précédemment, toute donnée relative
soit au serveur, soit à la requête du client se situe dans la variable
%ENV.

C'est moyen vrai. En tout cas, faux parfois :-)
Si vous faites du POST, le contenu du formulaire n'est pas dans %ENV,
mais sur STDIN.
D'où l'intérêt encore une fois d'utiliser le module CGI pour ces basses
besognes.

Et, même si j'en deviens lourd, encore une fois en mod_perl, rien ne
passe via %ENV (en tout cas par défaut), on attaque directement le coeur
interne d'Apache via une API dédiée.
Il est clair par contre que pour un débutant, c'est le bon bout pour
commencer :-)

Patrick.
(moi ? amateur de mod_perl ? non.... vous croyez :-) ?)

Ou, en plus haut niveau: WWW::Mechanize
un réel régal pour scripter un accès à un site web et en récupérer toutes
les informations dont on a besoin.

Patrick.

Je ne connaissais pas, je m'en irais essayer :-)


Julien

Le module CGI (ou CGI::Lite) s'occupe de tous les petits détails, et donc
simplifie grandement la tache. Un script CGI en perl peut alors tenir en
5 lignes:
#!/usr/bin/perl
use CGI;
my $q=CGI->new();
print $q->header();
print "Vous avez écrit: ".$q->param('texte');

(si j'ai le droit à une 6ème ligne, j'ajoute ``use strict;'')

Vous pouvez l'insérer sur la même ligne que "use CGI;" donc pas de 6e ligne
;o)

C'est moyen vrai. En tout cas, faux parfois :-)
Si vous faites du POST, le contenu du formulaire n'est pas dans %ENV,
mais sur STDIN.
D'où l'intérêt encore une fois d'utiliser le module CGI pour ces basses
besognes.

C'est vrai :-) et je m'en défend ainsi :
Je tenais à donner des explications complètes pour un débutant en Perl pour
HTTP, peut-être utilisateur de Perl de en général, j'ai donc opté pour une
simplification de cas qui se suffit à elle-même dans un premier temps. Pour
donner des explications plus complexe, j'ai pensé qu'il vallait mieux
attendre la confirmation des premiers pas dasn cette nouvelle orientation
(avec une utilisation réduite des outils qui simplifient la vie, afin de
mieux comprendre le fonctionnement de base de ce protocole).

Et, même si j'en deviens lourd, encore une fois en mod_perl, rien ne
passe via %ENV (en tout cas par défaut), on attaque directement le coeur
interne d'Apache via une API dédiée.
Il est clair par contre que pour un débutant, c'est le bon bout pour
commencer :-)

Je crois qu'en fait, justement dans ce cas, il n'est plus question de CGI,
mais d'API ou bien ISAPI (je fais que croire, je précise ;) ). Par contre,
je ne sais pas si les serveurs grand publique sont configurés pour utiliser
Perl de cette manière.

Patrick.
(moi ? amateur de mod_perl ? non.... vous croyez :-) ?)

L'intérêt que je pourrais y trouver est à tester :-)


Julien

CGI : Common Gateway Interface
C'est un protocole qui permet à un serveur web (soit un serveur http) de
transmettre des données à un programme executable par le serveur, et de
récupérer une réponse.

protocole ?

--
tyoup

(si j'ai le droit à une 6ème ligne, j'ajoute ``use strict;'')

Vous pouvez l'insérer sur la même ligne que "use CGI;" donc pas de 6e
ligne ;o)

A ce moment là, je mets tout sur une ligne !

C'est moyen vrai. En tout cas, faux parfois :-) Si vous faites du POST,
le contenu du formulaire n'est pas dans %ENV, mais sur STDIN. D'où
l'intérêt encore une fois d'utiliser le module CGI pour ces basses
besognes.

C'est vrai :-) et je m'en défend ainsi : Je tenais à donner des
explications complètes pour un débutant en Perl pour HTTP, peut-être
utilisateur de Perl de en général, j'ai donc opté pour une
simplification de cas qui se suffit à elle-même dans un premier temps.

Je suis tout à fait d'accord avec votre démarche, et vous en félicite.
Cependnt, même en simplifiant, dire que tout est dans %ENV est une
erreur, car le jour où votre débutant fais un formulaire avec
method=post, et ne trouve rien dans %ENV (parce qu'il fait tout à la main
et n'utilise pas CGI.pm), il sera troublé, non ?

Et, même si j'en deviens lourd, encore une fois en mod_perl, rien ne
passe via %ENV (en tout cas par défaut), on attaque directement le
coeur interne d'Apache via une API dédiée. Il est clair par contre que
pour un débutant, c'est le bon bout pour commencer :-)

Je crois qu'en fait, justement dans ce cas, il n'est plus question de
CGI, mais d'API ou bien ISAPI (je fais que croire, je précise ;) ).

C'est assez vrai, même si CGI reste là et qu'on le voit plus trop
(la sortie standard repart toujours vers le client, par exemple).

Par contre, je ne sais pas si les serveurs grand publique sont configurés
pour utiliser Perl de cette manière.

Rarement, par défaut en tout cas. Ce n'est pas trivial à faire proprement.

(moi ? amateur de mod_perl ? non.... vous croyez :-) ?)

L'intérêt que je pourrais y trouver est à tester :-)

Deux pistes:
- quand vous commencez à avoir de gros scripts et beaucoup d'accès
concurrents (le cache mod_perl aide grandement)
- quand vous voulez aller au-delà des CGI de base et vous interfacez à un
plus bas niveau avec Apache, notamment pour profiter de la possibilité de
répondre à la requête ``par étapes'' (gestionnaires Apache).

Bref, pour un script de 2 lignes ca sert à rien. Pour tout un site
complexe, c'est une piste.

Patrick.

A ce moment là, je mets tout sur une ligne !

Ah non ! Sur deux minimum ;-) (#!/user/bin/perl doit resté isolé) mais il
s'agissait d'une taquinerie :)

C'est vrai :-) et je m'en défend ainsi : Je tenais à donner des
explications complètes pour un débutant en Perl pour HTTP, peut-être
utilisateur de Perl de en général, j'ai donc opté pour une
simplification de cas qui se suffit à elle-même dans un premier temps.

Je suis tout à fait d'accord avec votre démarche, et vous en félicite.
Cependnt, même en simplifiant, dire que tout est dans %ENV est une
erreur, car le jour où votre débutant fais un formulaire avec
method=post, et ne trouve rien dans %ENV (parce qu'il fait tout à la main
et n'utilise pas CGI.pm), il sera troublé, non ?

Effectivement. Je tiens rigueur de la qualité de votre remarque et vous avez
par ailleurs bien fait de le noter pour Laurent.

Je crois qu'en fait, justement dans ce cas, il n'est plus question de
CGI, mais d'API ou bien ISAPI (je fais que croire, je précise ;) ).

C'est assez vrai, même si CGI reste là et qu'on le voit plus trop
(la sortie standard repart toujours vers le client, par exemple).

Peut-être effectivement que la notion de CGI demeure, il faudra que je me
renseigne à l'occasion.

Par contre, je ne sais pas si les serveurs grand publique sont
configurés

pour utiliser Perl de cette manière.

Rarement, par défaut en tout cas. Ce n'est pas trivial à faire proprement.

(moi ? amateur de mod_perl ? non.... vous croyez :-) ?)

L'intérêt que je pourrais y trouver est à tester :-)

Deux pistes:
- quand vous commencez à avoir de gros scripts et beaucoup d'accès
concurrents (le cache mod_perl aide grandement)
- quand vous voulez aller au-delà des CGI de base et vous interfacez à un
plus bas niveau avec Apache, notamment pour profiter de la possibilité de
répondre à la requête ``par étapes'' (gestionnaires Apache).

Bref, pour un script de 2 lignes ca sert à rien. Pour tout un site
complexe, c'est une piste.

Patrick.

Merci pour ces infos


Julien