Las capas detrás de una solicitud HTTPS de Mechanize a través de un proxy

Vea cómo Mechanize, el módulo de protocolo HTTPS de LWP y el backend SSL cooperan para encaminar, tunelizar y verificar una solicitud HTTPS.

Establezca la ruta en el objeto Mechanize antes de obtener:

use WWW::Mechanize;

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

Use el oyente HTTP previsto en el ejemplo; para solicitudes permitidas a destinos públicos, los candidatos están en la lista de proxies HTTP. La matriz nombra los esquemas de destino. El extremo http:// proporciona una ruta CONNECT ordinaria para HTTPS: HTTP hacia el proxy, túnel hacia el destino y luego TLS del destino. Si el despliegue usa en su lugar ajustes de entorno, $mech->env_proxy es la alternativa; importarlos después puede cambiar una ruta asignada en el código.

Mechanize hereda las funciones de red de LWP::UserAgent en lugar de ofrecer un motor de proxy HTTPS separado:

  • Mechanize aporta enlaces, formularios y el comportamiento de la página actual.
  • LWP::UserAgent y su transporte HTTP eligen la ruta y organizan el CONNECT.
  • LWP::Protocol::https aporta el manejo de HTTPS y eleva la conexión.
  • Net::HTTPS con su backend SSL aporta un socket compatible con TLS, normalmente IO::Socket::SSL en configuraciones modernas.

Un backend SSL instalado no selecciona un proxy por sí mismo. Mantenga el nombre de host HTTPS original en la URL: la aceptación de CONNECT no verifica el certificado de ese sitio.

Al mantener componentes antiguos, distinga estos límites. libwww-perl 6.06 y el LWP::Protocol::https 6.06 distribuido por separado introdujeron correcciones coordinadas para el CONNECT HTTP normal. La versión de UserAgent por sí sola no identifica el módulo HTTPS. LWP::Protocol::https 6.15 añadió una corrección para los extremos de proxy con TLS habilitado, cuyo esquema https:// añade TLS al proxy antes del TLS del destino.

Las configuraciones antiguas de Net::SSL/Crypt::SSLeay pueden usar en su lugar el mecanismo de entorno HTTPS_PROXY documentado de ese backend. No aplique su receta a la ruta moderna de IO::Socket::SSL, donde LWP controla el enrutamiento.

Use la primera etapa fallida para elegir el componente: un manejador HTTPS ausente atañe al módulo de protocolo; un CONNECT rechazado atañe a la ruta, las credenciales o la política; un error de certificado tras el túnel atañe a la identidad y la confianza del destino. Mantenga la verificación mientras cambia el componente que respalda esa evidencia.

Artículos relacionados