Die Ebenen hinter einer HTTPS-Anfrage von Mechanize über einen Proxy

Sehen Sie, wie Mechanize, LWPs HTTPS-Protokollmodul und das SSL-Backend zusammenarbeiten, um eine HTTPS-Anfrage zu leiten, zu tunneln und zu prüfen.

Legen Sie die Route am Mechanize-Objekt fest, bevor Sie abrufen:

use WWW::Mechanize;

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

Verwenden Sie im Beispiel den vorgesehenen HTTP-Listener; für erlaubte Anfragen an öffentliche Ziele stehen Kandidaten in der HTTP-Proxy-Liste bereit. Das Array benennt die Zielschemas. Der Endpunkt http:// liefert eine gewöhnliche CONNECT-Route für HTTPS: HTTP zum Proxy, Tunnel zum Ziel, dann TLS zum Ziel. Wenn das Deployment stattdessen Umgebungseinstellungen verwendet, ist $mech->env_proxy die Alternative; ein späterer Import kann eine im Code zugewiesene Route verändern.

Mechanize erbt die Netzwerkfunktionen von LWP::UserAgent, statt eine eigene HTTPS-Proxy-Engine bereitzustellen:

  • Mechanize liefert Links, Formulare und das Verhalten der aktuellen Seite.
  • LWP::UserAgent und sein HTTP-Transport wählen die Route und richten CONNECT ein.
  • LWP::Protocol::https liefert die HTTPS-Behandlung und wertet die Verbindung auf.
  • Net::HTTPS liefert mit seinem SSL-Backend einen TLS-fähigen Socket, in modernen Konfigurationen normalerweise IO::Socket::SSL.

Ein installiertes SSL-Backend wählt nicht selbst einen Proxy. Behalten Sie den ursprünglichen HTTPS-Hostnamen in der URL: Die Annahme von CONNECT prüft nicht das Zertifikat dieser Site.

Unterscheiden Sie beim Warten alter Komponenten diese Grenzen. libwww-perl 6.06 und das separat verteilte LWP::Protocol::https 6.06 führten abgestimmte Korrekturen für normales HTTP CONNECT ein. Die UserAgent-Version allein benennt nicht das HTTPS-Modul. LWP::Protocol::https 6.15 ergänzte eine Korrektur für TLS-fähige Proxy-Endpunkte, deren https://-Schema dem Proxy TLS hinzufügt, bevor das Ziel-TLS folgt.

Ältere Konfigurationen von Net::SSL/Crypt::SSLeay können stattdessen den dokumentierten Umgebungsmechanismus HTTPS_PROXY dieses Backends nutzen. Wenden Sie dessen Rezept nicht auf den modernen IO::Socket::SSL-Pfad an, in dem LWP das Routing besitzt.

Wählen Sie die Komponente anhand der ersten fehlgeschlagenen Stufe: Ein fehlender HTTPS-Handler betrifft das Protokollmodul; ein abgelehntes CONNECT betrifft Route, Zugangsdaten oder Richtlinie; ein Zertifikatsfehler nach dem Tunnel betrifft Identität und Vertrauen des Ziels. Behalten Sie die Prüfung bei, während Sie die Komponente wechseln, die dieser Befund stützt.

Ähnliche Artikel