Les couches derrière une requête HTTPS Mechanize via proxy

Voyez comment Mechanize, le module de protocole HTTPS de LWP et le backend SSL coopèrent pour router, tunneler et vérifier une requête HTTPS.

Définissez la route sur l'objet Mechanize avant la récupération :

use WWW::Mechanize;

my $mech = WWW::Mechanize->new(timeout => 30);
$mech->proxy(
    ['http', 'https'],
    'http://proxy.example.net:8080',
);

Utilisez l'écouteur HTTP prévu dans l'exemple ; pour les requêtes autorisées vers des cibles publiques, les candidats se trouvent dans la liste de proxys HTTP. Le tableau nomme les schémas de destination. Le point de terminaison http:// fournit une route CONNECT ordinaire pour HTTPS : HTTP vers le proxy, tunnel vers la cible, puis TLS cible. Si le déploiement utilise plutôt des paramètres d'environnement, $mech->env_proxy est l'alternative ; les importer ensuite peut modifier une route définie dans le code.

Mechanize hérite de la mise en réseau de LWP::UserAgent au lieu de fournir un moteur de proxy HTTPS distinct :

  • Mechanize fournit les liens, les formulaires et le comportement de la page courante.
  • LWP::UserAgent et son transport HTTP choisissent la route et organisent CONNECT.
  • LWP::Protocol::https assure la gestion HTTPS et met à niveau la connexion.
  • Net::HTTPS avec son backend SSL fournit la socket compatible TLS, généralement IO::Socket::SSL dans les configurations modernes.

Un backend SSL installé ne sélectionne pas lui-même un proxy. Conservez le nom d'hôte HTTPS d'origine dans l'URL : l'acceptation de CONNECT ne vérifie pas le certificat de ce site.

Lors de la maintenance d'anciens composants, distinguez ces frontières. libwww-perl 6.06 et LWP::Protocol::https 6.06, distribué séparément, ont introduit des correctifs coordonnés pour le CONNECT HTTP normal. La seule version de UserAgent n'identifie pas le module HTTPS. LWP::Protocol::https 6.15 a ajouté un correctif pour les points de terminaison de proxy compatibles TLS, dont le schéma https:// ajoute TLS au proxy avant le TLS cible.

Les configurations plus anciennes de Net::SSL/Crypt::SSLeay peuvent plutôt utiliser le mécanisme d'environnement HTTPS_PROXY documenté de ce backend. N'appliquez pas sa recette au chemin moderne IO::Socket::SSL, où LWP gère le routage.

Utilisez la première étape en échec pour choisir le composant : un gestionnaire HTTPS manquant concerne le module de protocole ; un CONNECT rejeté concerne la route, les identifiants ou la politique ; une erreur de certificat après le tunnel concerne l'identité et la confiance de la destination. Conservez la vérification lorsque vous changez le composant étayé par ces preuves.

Articles similaires