プロキシ経由の Mechanize 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 の拒否はルート、資格情報、ポリシーの問題です。トンネル後の証明書エラーは宛先の同一性と信頼の問題です。その証拠が支えるコンポーネントを変更する間も検証を維持してください。