프록시를 거치는 Mechanize HTTPS 요청 뒤의 계층

Mechanize, LWP의 HTTPS 프로토콜 모듈, SSL 백엔드가 하나의 HTTPS 요청을 라우팅, 터널링, 검증하기 위해 어떻게 협력하는지 봅니다.

가져오기 전에 Mechanize 객체에 경로를 설정합니다:

use WWW::Mechanize;

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

예제에 있는 의도된 HTTP 리스너를 사용하십시오. 허용된 공개 대상 요청의 경우 후보는 HTTP 프록시 목록에 있습니다. 배열은 대상 스킴을 지정합니다. http:// 엔드포인트는 HTTPS용 일반 CONNECT 경로를 제공합니다. 프록시로 HTTP, 대상으로 터널, 그다음 대상 TLS입니다. 배포가 대신 환경 설정을 사용한다면 $mech->env_proxy가 대안입니다. 나중에 가져오면 코드에서 할당한 경로가 바뀔 수 있습니다.

Mechanize는 별도의 HTTPS 프록시 엔진을 제공하는 대신 LWP::UserAgent 네트워킹을 상속합니다:

  • Mechanize는 링크, 폼, 현재 페이지 동작을 제공합니다.
  • LWP::UserAgent와 그 HTTP 전송이 경로를 선택하고 CONNECT를 준비합니다.
  • LWP::Protocol::https가 HTTPS 처리를 제공하고 연결을 업그레이드합니다.
  • Net::HTTPS는 SSL 백엔드와 함께 TLS 지원 소켓을 제공하며, 현대 구성에서는 보통 IO::Socket::SSL입니다.

설치된 SSL 백엔드는 스스로 프록시를 선택하지 않습니다. 원래 HTTPS 호스트 이름을 URL에 유지하십시오. CONNECT 수락은 해당 사이트의 인증서를 검증하지 않습니다.

오래된 구성 요소를 유지 관리할 때는 이 경계를 구분하십시오. libwww-perl 6.06과 별도로 배포되는 LWP::Protocol::https 6.06은 일반 HTTP CONNECT에 대한 협조된 수정을 도입했습니다. UserAgent 버전만으로는 HTTPS 모듈을 식별할 수 없습니다. LWP::Protocol::https 6.15는 TLS 지원 프록시 엔드포인트에 대한 수정을 추가했으며, 그 https:// 스킴은 대상 TLS 전에 프록시에 TLS를 추가합니다.

더 오래된 Net::SSL/Crypt::SSLeay 구성은 대신 해당 백엔드의 문서화된 HTTPS_PROXY 환경 메커니즘을 사용할 수 있습니다. 그 레시피를 LWP가 라우팅을 담당하는 현대적 IO::Socket::SSL 경로에 적용하지 마십시오.

첫 번째 실패 단계로 구성 요소를 선택하십시오. HTTPS 핸들러가 없으면 프로토콜 모듈 문제입니다. CONNECT가 거부되면 경로, 자격 증명 또는 정책 문제입니다. 터널 후 인증서 오류는 대상의 ID와 신뢰 문제입니다. 그 증거가 뒷받침하는 구성 요소를 변경하는 동안 검증을 유지하십시오.

관련 글