curl kan ikke læse din PAC-fil: send proxyen i stedet

PAC-filens adresse og proxyens endepunkt ser ud til at kunne udskiftes i en konfigurationsfil, og det kan de ikke. Det ene er et politikprogram, der skal evalueres for hver URL; det andet er et værtsnavn og en port, der accepterer forbindelser. curl forstår kun det andet. At sende en PAC-adresse til --proxy er en kategorifejl, der fejler på en forvirrende måde, normalt efter en lang CONNECT-timeout til en webserver.

Hvad hver af dem egentlig er

Det siger FAQ om curl klart: curl tilbyder ikke JavaScript- eller PAC-fortolkning. En PAC-bevidst indpakning omkring curl kan gøre det, men curl selv gør det ikke, og ingen flag gør den til en browser.

Hvorfor browseren virker, og curl ikke gør

En browser integrerer med systemets proxykonfiguration, henter PAC-filen og kører dens regler mod den URL, du åbner. Den evaluering er den tjeneste, PAC-filen leverer, og den sker inde i browseren, ikke inde i din terminal.

At hente PAC-filen med curl giver kun dens tekst. Det får ikke curl til at udføre politikken, og at læse den manuelt for at finde en proxy er en manuel version af samme evaluering med samme chance for at vælge den forkerte gren. Hvis du læser den, så læs den return-sætning, der passer til din vært, i stedet for det første proxynavn i filen. De fleste PAC-filer indeholder flere, og kun én gren gælder for dig.

For en godkendt HTTP-proxy og en godkendt HTTPS-tjeneste er en illustrativ anmodning:

curl --proxy http://proxy.corp.example:8080 https://service.example.net/status

Den første adresse er proxylytteren, den anden er den tjeneste, du vil have. Det er eksempelendepunkter og ikke en test, nogen har udført, så erstat dem med din organisations skema, port og godkendelsesarbejdsgang.

Vælg proxyen til denne destination

Spørg administratoren, hvilken proxy politikken vælger til den URL, du har brug for, ikke hvilken proxy organisationen ejer. PAC-regler kan give forskellige resultater for interne tjenester, offentlige websteder og failover-tilstande, og en regel, der passer til din URL i dag, kan efter en redigering passe til en anden.

Hvis arbejdsgangen har brug for mere end én kendt anmodning, brug en statisk indstilling, som administratoren understøtter, eller en godkendt PAC-bevidst integration. At hardcode én kopieret adresse virker indtil den dag, politikken ændres, og ingen længere husker, hvorfor den adresse blev valgt.

Se derefter på, hvad curl arver. Proxy-miljøvariabler og NO_PROXY kan tilsidesætte eller udelukke den proxy, du sendte, og en udelukkelse, der matcher dit mål, sender anmodningen direkte uden at sige det. Bevar den tilsigtede politik i stedet for at slette hver udelukkelse eller tvinge alt gennem én adresse. Kør anmodningen én gang med -v og kontroller, hvilken adresse den faktisk oprettede forbindelse til.

Hold de to TLS-identiteter adskilt

Med en HTTPS-proxy er der to TLS-forbindelser i spil: din til proxyen og proxyens til destinationen. Hver har sin egen identitet at verificere, og at slå verifikationen fra for en af dem er ikke en PAC-løsning, det er et andet problem oveni det første.

Lad verifikationen være slået til, og læs den fejl, du får. En proxygodkendelsesudfordring, en utilgængelig proxy og en afvisning fra webstedet er tre forskellige resultater, og kun det første handler om legitimationsoplysninger. VPN skal stadig give en tilladt vej til en privat proxy, inklusive navneopløsning for selve proxyværten, før noget af dette kan lykkes.

Skriv endepunktet, skemaet, porten, godkendelsesmetoden, udelukkelserne og VPN-vejen til proxyen ned. Den registrering er det, der gør den næste anmodning reproducerbar, og det er forskellen mellem at kende sin proxy og at gætte på den.