La librairie `libwww-perl`

Pour accéder au web en Perl, il est heureusement inutile d'ouvrir vos connexions vous-mêmes et d'envoyer des GET / HTTP/1.0 dessus. Ce serait ré-inventer une roue particulièrement ronde : la librairie libwww-perl ou LWP. Il s'agit d'un ensemble de modules Perl pour accéder au web (et plus), dont la création et le développement ont été coordonnés par Gisle Aas depuis 1995, à partir de la librairie libwww-perl écrite pour Perl 4 par Roy Fielding (l'un des auteurs du RFC concernant HTTP). Comme vous allez le voir dans la suite de cet article, LWP est l'outil indispensable pour l'écriture de clients HTTP en Perl.

Présentation de LWP

LWP est une librairie orientée objet qui utilise beaucoup les notions d'héritage et d'encapsulation et s'appuie sur le modèle de communication HTTP. C'est-à-dire que la communication se déroule toujours de la même façon : une requête (un objet HTTP::Request) est construite, puis envoyée au serveur qui renvoie une réponse (un objet HTTP::Response), qui contient les informations requises. HTTP est un protocole sans mémoire, ce qui signifie que chaque requête est traitée indépendamment des autres. LWP s'appuie sur ce modèle de communication pour réaliser non seulement des requêtes HTTP, mais aussi ftp, gopher, SMTP, des accès au système de fichier local, etc.

Cette partie va introduire quelques-uns des modules principaux de la librairie LWP. Ne vous inquiétez pas si tout ne vous paraît pas clair au début, cette série d'articles se poursuivra par des exemples largement commentés. En ce qui concerne l'API complète (liste des méthodes et attributs), je vous renvoie à la documentation en ligne.

LWP::UserAgent
C'est le module principal. Il s'agit d'un client qui supporte de nombreux protocoles, à travers le modèle HTTP (une requête donnant lieu à une réponse). Afin de pouvoir travailler avec le protocole HTTP, de nombreux modules objets (pour la plupart décrits ci-après) représentent les divers éléments d'une connexion.

C'est un objet LWP::UserAgent qui prend votre requête (HTTP::Request) et la passe au serveur pour obtenir une réponse (HTTP::Response). L'initialisation se fait comme d'habitude, avec la méthode new().
```
    my $ua = LWP::UserAgent->new( agent => "MonAgent/0.02" );
```
Notez que le constructeur de LWP::UserAgent accepte des options comme agent ou timeout, qui peuvent également être mises à jour avec les accesseurs correspondants (agent(), timeout(), etc.).

LWP::UserAgent dispose de plusieurs méthodes pour exécuter les requêtes : send_request(), simple_request() et request(). Les différences entre ces méthodes sont liées à l'existence ou non d'un pré-traitement de la requête et du suivi automatique des redirections (codes HTTP 3xx).

Nous ne rentrerons pas dans les détails des protocoles autres que HTTP, mais sachez que LWP supporte également les protocoles ftp, gopher et autres de la même façon, à l'aide d'objets HTTP::Request et HTTP::Response. Les menus ftp et gopher sont même convertis en HTML au vol.
HTTP::Request
HTTP::Response
Ces deux modules sont des sous-classes de HTTP::Message destinées à encapsuler les requêtes HTTP et les réponses associées. HTTP::Message est leur classe ancêtre commune et abstraite qui gère la logique en-tête et corps de message.

HTTP::Request dispose d'accesseurs comme method(), uri(), content() (le corps de la requête, utilisé par exemple avec la méthode POST) ou headers() (qui donne accès à l'objet HTTP::Headers représentant les en-têtes du message).

HTTP::Response fournit (entre autres) les accesseurs code() (code de statut de la réponse), content() (le corps de la réponse, en général la page web demandée) ou headers() (encore les en-têtes). Le module dispose également de fonctions utilitaires comme is_success(), is_error() ou is_redirect() qui permettent de connaître l'état de la réponse sans forcément regarder son code (200, 404, etc.).
HTTP::Headers
Ce module encapsule les en-têtes d'un message HTTP, et vous donne accès à ceux-ci.

Il dispose de méthodes d'accès aux différents en-têtes :
```
    # $req est un objet HTTP::Request
    my $h = $req->headers();

    # affiche "libwww-perl/5.69"
    print $h->header( 'User-Agent' );

    # modifie un en-tête
    $h->header( User_Agent => 'Mozilla/5.0' );

    # supprime un en-tête
    $h->remove_header( 'Referer' );
```
Notez que pour les en-têtes contenant un tiret (comme User-Agent, ou Content-Type), on peut remplacer celui-ci par un caractère souligné (underscore ou _), afin de se passer de guillemets lors de l'affectation d'un en-tête. En effet, l'opérateur => fournit un contexte de chaîne à sa gauche à condition de suivre un mot simple (bareword).
HTTP::Cookies
Parmi les en-têtes HTTP se trouvent ceux qui gèrent les cookies. Ce module permet à votre client de gérer automatiquement les cookies reçus et envoyés, de les sauver et de les restaurer au prochain lancement de votre script, ou à partir du fichier de cookies de votre navigateur.

L'utilisation de ce module est expliquée en détail dans cet article.
HTML::Form
HTML::Form donne aux formulaires HTML une interface objet. Les objets HTML::Form sont créés directement à partir d'un document HTML :
```
    @forms = HTML::Form->parse( $document_html, $base_uri )
```
Le tableau @forms contient un objet HTML::Form par formulaire contenu dans le document HTML. Afin que l'on puisse ensuite construire la requête correspondant à la validation du formulaire, il est indispensable de fournir l'URI ayant permis d'obtenir le document.

Il existe un constructeur new(), mais il est en général peu utilisé.

Un formulaire contient un certain nombre de champs d'entrée, qui sont des objets de type HTML::Form::Input (éventuellement plus spécialisés). Diverses méthodes permettent d'accéder aux champs et de les modifier.
```
    # retourne la liste des champs du formulaire
    my @inputs = $form->inputs();

    # trouve le champ nommé 'password'
    my $input = $form->find_input('password');
```
Une fois qu'on dispose d'une référence à un champ du formulaire, on peut l'utiliser comme dans son navigateur habituel :
```
    # change le mot de passe (les deux formes sont équivalentes)
    $form->find_input('password')->value('S3kr3t');
    $form->value( password => 'S3kr3t' );
```
Parmi les méthodes disponibles, on trouve : type(), qui renvoie le type de champ (c'est-à-dire button, checkbox, file, hidden, image, option, password, radio, reset, submit ou textarea), name() et value() (ce sont des accesseurs qui permettent d'obtenir ou de modifier le nom ou la valeur courante du champ), possible_values() , qui renvoie la liste des valeurs possibles (ou une liste vide, si le champ ne propose pas un liste prédéfinie de valeurs).

Enfin, la méthode click() permet de valider le formulaire, et renvoie un objet HTTP::Request, directement utilisable par votre LWP::UserAgent.
HTTP::Daemon
La librairie LWP contient même une classe qui permet de créer des serveurs HTTP de façon simple et rapide. Ce n'est pas Apache, bien sûr, mais c'est parfois suffisant.
LWP::Simple
LWP::Simple est un module à l'interface fonctionnelle qui permet de répondre aux besoins simples de connexion (récupérer le contenu d'une page web). Très utile pour des opérations simples, il montre rapidement ses limites.

get() retourne le document correspondant à l'URL passé en paramètre, et undef en cas d'erreur.
```
    # $url est une chaîne ou un objet URI
    my $page = get($url);
```
head() permet de récupérer certaines informations à partir d'une requête HEAD sur l'URL demandée. En contexte de liste, on obtient (dans l'ordre) le type du message (Content-Type), la taille du document (Content-Length), la date de dernière modification (Last-Modified), la date d'expiration (Expires) et l'identification du serveur (Server) en cas de succès et une liste vide en cas d'échec.
```
    $ perl -MLWP::Simple -le '$,=$/;print head"http://www.mongueurs.net/"'
    text/html; charset=iso-8859-1
    3797
    1066569963
    
    Apache/1.3.27 (Unix)
```
En contexte scalaire, la fonction retourne une valeur vraie ou fausse selon que le document est disponible ou non.

getprint() fonctionne comme get() mais imprime le contenu de la page demandée sur STDOUT. En cas d'erreur, imprime le code d'erreur et le message associé. La valeur de retour est le code de réponse HTTP.

getstore() enregistre le corps de la réponse dans le fichier passé en paramètre, et retourne le code de réponse HTTP.

mirror() fait la même chose que getstore(), mais s'appuie sur l'en-tête de requête If-modified-Since et sur l'en-tête de réponse Content-Length.

Dès que vous avez besoin d'un peu plus de détails sur la réponse ou dans l'élaboration de la requête (pour faire un POST, par exemple), c'est le signe qu'il est temps d'utiliser LWP::UserAgent.

LWP::Debug

Le chargement de ce module force LWP::UserAgent à afficher ce qu'il fait. Il est très utile pour le débogage d'un script.

On peut afficher (ou non) trois niveaux de messages : trace (appels de fonctions), debug (messages de débogage) et conns (les données transférées par les connexions). La fonction level() permet de contrôler ce qu'on veut afficher, en lui passant en paramètre le nom du niveau de log désiré, préfixé d'un + ou d'un -. Il est également possible de passer directement les paramètres lors de l'importation du module.

    # affiche tout
    use LWP::Debug qw(+);

    # n'affiche rien
    use LWP::Debug qw(-);

    # affiche tout sauf les connexions
    use LWP::Debug qw(+ -conns);

    # utilisation de la fonction level()
    use LWP::Debug qw(level);
    level('+');
    level('-conns');

Voici un exemple de ce que LWP::Debug peut afficher pour un simple appel à la méthode getprint() de LWP::Simple :

    $ perl -MLWP::Debug=+ -MLWP::Simple -e 'getprint"http://www.mongueurs.net/"'
    LWP::UserAgent::new: ()
    LWP::UserAgent::request: ()
    LWP::UserAgent::send_request: GET http://www.mongueurs.net/
    LWP::UserAgent::_need_proxy: Not proxied
    LWP::Protocol::http::request: ()
    LWP::Protocol::collect: read 755 bytes
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
    <html>
    <head>
    ...

Retour à notre exemple

Voici donc comment récupérer la page principale du site de Paris.pm avec LWP::Simple :

    #!/usr/bin/perl -w
    use strict;
    use LWP::Simple;

    # récupère le corps de la réponse
    my $content = get('http://paris.mongueurs.net/');

Difficile de faire plus simple ! Sa simplicité est en fait la principale limitation de LWP::Simple : il ne donne pas accès aux en-têtes, et la méthode get() retourne un simple undef en cas d'erreur. Il est donc impossible de savoir si on a affaire à une erreur 404 ou à un dépassement du délai de garde de la connexion (timeout).

Pour accéder à toutes les informations concernant votre connexion HTTP, il vous faudra utiliser LWP::UserAgent et les objets qu'il emploie :

    #!/usr/bin/perl -w
    use strict;
    use LWP::UserAgent;

    # crée un agent et une requête
    my $ua  = LWP::UserAgent->new();
    my $req = HTTP::Request->new( GET => 'http://paris.mongueurs.net/' );

    # récupère la réponse
    my $res = $ua->request($req);

L'objet $res retourné par la méthode request() est de type HTTP::Response. Vous pouvez obtenir l'objet HTTP::Headers qui représente les en-têtes de cette réponse avec la méthode headers() et le corps du message avec la méthode content().

Utilisation avancée de LWP

Importation de cookies

Encore une dernière remarque au sujet des cookies : votre navigateur enregistre lui aussi des cookies sur le disque. Pourquoi ne pas aller chercher celui qui vous intéresse directement dans le fichier correspondant ?

Vous trouverez, dans la distribution standard de LWP ou sur CPAN, des modules qui se chargent de lire les cookies stockés au format propriétaire de votre navigateur et de les ajouter à un objet dérivé de HTTP::Cookies, celui-ci pouvant être utilisé par votre agent. Ceci pourra par exemple vous permettre de surfer avec votre navigateur habituel, puis de convertir les cookies qu'il aura récupérés au format HTTP::Cookies, afin de les utiliser dans vos scripts. Et vous n'aurez pas besoin de faire vous même la conversion entre le format natif de votre navigateur et le format interne HTTP::Cookies avant utilisation.

Les modules existants à ce jour sont : HTTP::Cookies::Netscape, HTTP::Cookies::Mozilla, HTTP::Cookies::Microsoft, HTTP::Cookies::iCab, HTTP::Cookies::Safari et HTTP::Cookies::Omniweb.

Voici un exemple de script de conversion des cookies Mozilla en cookies LWP. Il traduit le contenu du fichier Mozilla-cookies.txt (format Mozilla) et le sauve dans un fichier cookies.txt utilisable directement par le module HTTP::Cookies :

    #!/usr/bin/perl -w
    use strict;
    use HTTP::Cookies::Mozilla;

    my $cookies = HTTP::Cookies::Mozilla->new( file => 'Mozilla-cookies.txt' );
    HTTP::Cookies::save( $cookies, 'LWP-cookies.txt' );

La dernière ligne force l'objet $cookies à être sauvegardé avec la méthode save() de HTTP::Cookies, et non celle de HTTP::Cookies::Mozilla (qui sauve les cookies au format Mozilla). Pour adapter ce script à votre navigateur, il suffit simplement d'utiliser le module correspondant.

Utilisation d'un proxy

LWP::UserAgent supporte l'utilisation d'un serveur mandataire (proxy). C'est la méthode proxy() qui permet de le définir :

    $ua->proxy( 'http', 'http://proxy.example.com:3128/');

Si le proxy supporte plusieurs protocoles, il faut utiliser une référence à un tableau :

    $ua->proxy(['http', 'ftp'], 'http://proxy.example.com:8080/');

Si un mot de passe est nécessaire pour utiliser le proxy, la chaîne de description correspondante sera : http://user:pass@proxy.example.com:8080/.

Il est également possible d'utiliser une variable d'environnement pour définir le proxy à utiliser.

Pour utiliser les variables d'environnement, il faut initialiser l'agent de la façon suivante :

    my $ua = LWP::UserAgent->new( env_proxy => 1 );

La variable d'environnement utilisée par LWP::UserAgent est HTTP_PROXY (FTP_PROXY pour le proxy ftp, etc.). Notez que LWP::UserAgent ne tient pas compte de la casse : il retrouvera son proxy que la variable d'environnement s'appelle http_proxy, HTTP_PROXY ou encore HtTp_PrOxY.

L'avantage d'utiliser une variable d'environnement est qu'il est alors possible d'écrire un script très général, qu'un utilisateur devant utiliser un proxy pourra utiliser sans le modifier. Mais on peut tout aussi bien ajouter une option --proxy à son script (au sujet des options, voir l'article de Jérôme Quelin dans Linux Magazine 49).

Gestion de formulaires complexes

HTML::Form est assez simple à utiliser avec un formulaire de recherche classique, où il s'agit en général de remplir le champ texte correspondant à la requête.

Pour une simple requête Google, par exemple,

    #!/usr/bin/perl -w
    use strict;
    use LWP::UserAgent;
    use HTML::Form;

    my $ua = LWP::UserAgent->new( env_proxy => 1, agent => "Mozilla/5.0" );
    my $base = 'http://www.google.fr/';
    my $res  = $ua->request( HTTP::Request->new( GET => $base ) );
    my $form = HTML::Form->parse( $res->content );
    $form->value( q => shift );
    $res = $ua->request( $form->click );

Et $res contient la réponse HTTP faite par Google à votre requête.

Note : Google s'appuie sur l'en-tête User-Agent pour refuser les requêtes automatiques ; c'est pourquoi nous avons utilisé l'attribut agent. De toute façon, si vous voulez faire des requêtes sur Google de façon automatique, les conditions d'utilisation de Google (http://www.google.com/terms_of_service.html) l'interdisent. Pour cela, il est recommandé d'utiliser les API que Google met à la disposition des développeurs.

Dans la suite de cette partie, nous allons voir comment valider les champs ayant un nombre limité de valeurs possibles. Ils sont de type radio, checkbox ou select ; les objets correspondants sont tous de la classe HTML::Form::ListInput. Ces champs portent tous le même nom, ce qui peut poser problème, puisque la fonction value() (utilisée dans l'exemple $form->value( q => "test" ) cité précédemment) ne permet que de modifier le premier champ de même nom.

Nous allons donc voir comment remplir un formulaire à partir d'un petit exemple de source HTML :

    <form method="POST" action="/sondage.pl">
    <p>Quelles sont vos couleurs préférées&nbsp;?</p>
    <p>
    <input type="checkbox" name="RGB" value="rouge" /> Rouge
    <input type="checkbox" name="RGB" value="vert" /> Vert
    <input type="checkbox" name="RGB" value="bleu" /> Bleu
    </p><p>
    <input type="radio" name="CYMK" value="cyan" checked /> Cyan
    <input type="radio" name="CYMK" value="jaune" /> Jaune
    <input type="radio" name="CYMK" value="magenta" /> Magenta
    </p>
    <p>Et vos fruits et légumes préférés&nbsp;?</p>
    <select name="FRUITS" multiple>
    <option value="pommes">pommes
    <option value="poires">poires
    <option value="bananes">bananes
    <option value="oranges">oranges
    </select>
    <select name="LEGUMES">
    <option value="brocolis">brocolis
    <option value="carottes">carottes
    <option value="courgettes">courgettes
    </select>
    <p><input type="submit" value="Valider" /></p>
    </form>

Voici ce qu'un navigateur affichera en le recevant :

Une fois l'objet $form créé avec HTML::Form->parse(), on peut l'afficher avec sa méthode dump() :

    POST http://example.com/sondage.pl
      RGB=<UNDEF>                     (checkbox) [*<UNDEF>|rouge]
      RGB=<UNDEF>                     (checkbox) [*<UNDEF>|vert]
      RGB=<UNDEF>                     (checkbox) [*<UNDEF>|bleu]
      CYMK=<UNDEF>                    (radio)   [cyan|jaune|magenta]
      FRUITS=<UNDEF>                  (option)  [*<UNDEF>|pommes]
      FRUITS=<UNDEF>                  (option)  [*<UNDEF>|poires]
      FRUITS=<UNDEF>                  (option)  [*<UNDEF>|bananes]
      FRUITS=<UNDEF>                  (option)  [*<UNDEF>|oranges]
      LEGUMES=brocolis                (option)  [*brocolis|carottes|courgettes]
      <NONAME>=Valider                (submit)

Les * correspondent aux valeurs « déjà vues » pour ce champ par l'objet HTML::Form (explications ci-dessous).

Tout d'abord, il convient de noter que les champs checkbox et select/multiple sont traités différement des champs radio et select sans l'option multiple. Cela vient du fait que les premiers permettant de faire une selection multiple, ils peuvent apparaître plusieurs fois dans la requête générée (par exemple RGB=rouge&RGB=bleu&FRUITS=poires&FRUITS=oranges&LEGUMES=brocolis) et que le CGI recevant cette requête sait traiter une telle requête.

Nous pouvons commencer à essayer de modifier les valeurs des champs. Nous testerons ce qui sera renvoyé en analysant la requête générée à partir du formulaire modifié.

    # valide le formulaire sans modification
    print $form->click()->content();

Ceci affiche :

    LEGUMES=brocolis

Première remarque, les champs de type select sans l'option multiple ayant nécessairement une valeur sélectionnée, celle-ci est toujours renvoyée, ce qui n'est pas le cas pour les champs de type checkbox ou les select avec l'option multiple.

Commençons par tester la boîte de sélection simple et les boutons radio :

    # radio
    $form->value( CYMK => 'jaune' );
    $form->value( CYMK => 'cyan' );
    # select sans l'option multiple
    $form->value( LEGUMES => 'carottes' );
    $form->value( LEGUMES => 'courgettes' );
    # le résultat
    print $form->click()->content();

Le corps de la requête envoyée sera :

    CYMK=cyan&LEGUMES=courgettes

Pour ces deux types de champs, comme il se doit, seule la dernière valeur sélectionnée est passée lors de l'envoi du formulaire.

Si on tente de sélectionner une valeur non proposée, cela provoquera une erreur (la méthode value() meurt en faisant appel à Carp::croak()) :

    # valeur illégale
    $form->value( CYMK => 'blanc' );
    Illegal value 'blanc' at exemple.pl line 13

Note : Pour éviter que votre programme ne meure brutalement, vous pouvez bien sûr utiliser le mécanisme d'exceptions associé à eval { } et traiter le message d'erreur contenu dans la variable standard $@ (pour la gestion d'exceptions en Perl, je vous renvoie à mon article de Linux Magazine 52, Les variables standard de Perl).

Voyons maintenant les champs avec des sélections multiples (checkbox et select avec l'option multiple) :

    # checkbox
    $form->value( RGB => 'rouge');
    $form->value( RGB => 'bleu');

Ceci donne l'erreur Illegal value 'bleu'. La valeur rouge ne provoque pas d'erreur, mais la valeur bleu en provoque une ? Souvenez-vous que la méthode find_input() (utilisée par value()) ne trouve que le premier de tous les champs de même nom. Or dans le cas des checkbox (comme celui des select/multiple), HTML::Form crée un objet de type HTML::Form::Input par valeur possible, ainsi que nous l'avons vu dans le résultat de dump(). Le premier champ trouvé portant le nom RGB n'a que deux valeurs possibles : UNDEF et rouge. On peut le vérifier en utilisant la méthode possible_values() dans l'exemple suivant :

    use Data::Dumper;
    # valeurs possibles de la première checkbox nommée RGB
    my $input = $form->find_input( 'RGB' );
    print Dumper [ $input->possible_values() ];

Ce qui affiche :

    $VAR1 = [
              undef,
              'rouge'
            ];

L'erreur rencontrée précédemment s'explique ainsi facilement. Il faudra donc sélectionner les cases à cocher d'une autre manière.

La méthode find_input() accepte heureusement d'autres arguments que le simple nom du champ. Le deuxième argument impose le type du champ à trouver (au cas où plusieurs champs différents porteraient le même nom) et le troisième permet d'imposer le numéro d'ordre du champ à trouver (en comptant à partir de 1). On peut ainsi sélectionner les cases voulues, pourvu qu'on connaisse leur ordre d'apparition dans le formulaire :

    # checkbox
    $form->find_input( 'RGB', undef, 1 )->value(undef);
    $form->find_input( 'RGB', undef, 2 )->value('vert');
    $form->find_input( 'RGB', undef, 3 )->value('bleu');

Ce qui coche les cases vert et bleu, tout en décochant la case rouge :

    RGB=vert&RGB=bleu&LEGUMES=brocolis

Une autre possibilité est d'obtenir la liste des champs à l'aide de inputs() et de boucler dessus pour les modifier. Nous allons également utiliser la méthode possible_values(), qui (comme son nom l'indique) liste l'ensemble des valeurs possibles pour ce champ. Si le champ n'a pas un nombre limité de valeurs possibles, cette méthode retourne une liste vide.

Voici un exemple permettant de sélectionner seulement les fruits poires et bananes :

    # récupère les champs nommés FRUITS
    for my $input
        ( grep { defined $_->name && $_->name eq 'FRUITS' } $form->inputs )
    {
        # valide ceux qui acceptent 'poires' ou 'bananes' comme valeur
        $input->value($_)
          for grep { defined && /poires|bananes/ } $input->possible_values();
    }

En général, utiliser find_input() avec trois paramètres est un peu plus compréhensible. Cela nécessite juste d'être certain de la présentation du formulaire, puisque le troisième paramètre dépend de l'ordre dans lequel les balises <input> sont insérées dans le code HTML.

À titre d'information, sachez qu'il existe également une méthode other_possible_values() qui liste l'ensemble des valeurs non encore utilisées pour un champ. Il y a toujours au moins une valeur par défaut qui a été prise, ainsi qu'on l'a vu plus haut avec le résultat de dump() (les valeurs marquées par *).

    # trouve le premier champ FRUITS
    my $input = $form->find_input('FRUITS');
    print "Possibles : ", map( {"<$_>"} $input->possible_values() ),       "\n";
    print "Restantes : ", map( {"<$_>"} $input->other_possible_values() ), "\n";
    # sélectionne une valeur
    $input->value('pommes');
    print "Restantes : ", map( {"<$_>"} $input->other_possible_values() ), "\n";

L'exemple ci-dessus affichera (avec un message d'avertissement à cause de l'utilisation d'undef dans le premier map) :

    Possibles : <><pommes>
    Restantes : <pommes>
    Restantes :

Rien n'est affiché à la fin, car toutes les valeurs possibles (undef et pommes) ont été sélectionnées au moins une fois.

Je ne présente pas la méthode try_others, car je ne lui ai pas encore trouvé d'utilité.

LWP, Le Web en Perl (1)

Chapeau

Automatiser le surf

La librairie `libwww-perl`

Présentation de LWP

Retour à notre exemple

Exemple d'automatisation : perlmonks

Un script de connexion simple

Utilisation de cookies

Utilisation avancée de LWP

Importation de cookies

Utilisation d'un proxy

Gestion de formulaires complexes

Et la performance ?

Conclusion

Références

L'auteur

LWP, Le Web en Perl (1)

Chapeau

Automatiser le surf

La librairie libwww-perl

Présentation de LWP

Retour à notre exemple

Exemple d'automatisation : perlmonks

Un script de connexion simple

Utilisation de cookies

Utilisation avancée de LWP

Importation de cookies

Utilisation d'un proxy

Gestion de formulaires complexes

Et la performance ?

Conclusion

Références

L'auteur

La librairie `libwww-perl`