Agordi HTTP-proksejon por la HTTP-skemo ne nepre agordas HTTPS-peton. En LWP, la skemo de la petita URLo decidas kiun proksejan mapadon oni konsultas.

Eksplicita komuna finpunkto povas esti asignita al ambaŭ skemoj:

use LWP::UserAgent;

my $ua = LWP::UserAgent->new(timeout => 15);
$ua->proxy(['http', 'https'], 'http://proxy.example.net:8080');
my $response = $ua->get('https://example.com/');

Por permesitaj publikaj petoj, la listo de HTTP-proksejoj proponas kandidatojn por la komuna LWP-prokseja URLo. La celo estas HTTPS dum la prokseja URLo estas HTTP. Tio estas normala CONNECT-aranĝo, ne kialo renomi la proksejan skemon al HTTPS.

Se la aplikaĵo devas legi proksejajn medivariablojn, elektu tiun diskovron per env_proxy. Variablo ĉeesta en la ŝelo ne utilas se ĉi tiu kliento neniam importas ĝin. Kontrolu la koncernan HTTPS-agordon kaj la pretervojojn, ne nur la HTTP-valoron.

Tenu la elektitan fonton de agordo intence. Importi medagordojn post eksplicita asigno povas igi la rezulton malsama ol la finpunkto, kiun la kodo ŝajne elektas.

Atestila fido kaj reteja aŭtentikigo restas apartaj de prokseja enkursigado. Diagnozu rektan konekton, proksejan malakcepton kaj postan TLS-eraron en iliaj propraj etapoj anstataŭ anstataŭigi ĉiujn agordojn samtempe.

Rilataj artikoloj