curl kan ikkje lese PAC-filen din: send proxyen i stedet

Adressa til PAC-filen og endepunktet til proxyen ser ut som om de kan byttes om i en konfigurasjonsfil, og det kan dei ikkje. Det eine er et policyprogram som må evalueres for hver URL; det andre er et vertsnavn og en port som tar imot tilkoblinger. curl forstår berre det andre. Å sende en PAC-adresse til --proxy er ein kategorifeil som feilar på ein forvirrande måte, vanlegvis etter ein lang CONNECT-tidsavbrot mot ein webserver.

Kva kvar av dei eigentleg er

Det seier FAQ-en for curl klart: curl tilbyr ingen JavaScript- eller PAC-tolkning. En PAC-bevisst innpakning rundt curl kan gjera det, men curl sjølv gjer det ikkje, og ingen flagg gjer han til ein nettlesar.

Kvifor nettlesaren verkar og curl ikkje

Ein nettlesar integrerer med proxykonfigurasjonen til systemet, hentar PAC-fila og køyrer reglane hennar mot URL-en du opnar. Den evalueringa er tenesta PAC-fila leverer, og ho skjer inne i nettlesaren, ikkje inne i terminalen din.

Å henta PAC-fila med curl gir berre teksten. Det får ikkje curl til å køyra policyen, og å lesa henne manuelt for å finna ein proxy er ein manuell versjon av same evalueringa, med same sjanse for å velja feil grein. Viss du les henne, les return-setninga som passar til verten din i staden for det første proxynamnet i fila. Dei fleste PAC-filer inneheld fleire, og berre éi grein gjeld for deg.

For ein godkjend HTTP-proxy og ei godkjend HTTPS-teneste er ein illustrerande førespurnad:

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

Den første adressa er proxy-lyttaren, den andre er tenesta du vil ha. Dette er døme-endepunkt og ikkje ein test nokon har utført, så byt dei ut med skjemaet, porten og autentiseringsflyten til organisasjonen.

Vel proxyen for denne destinasjonen

Spør administratoren kva for ein proxy policyen vel for URL-en du treng, ikkje kva for ein proxy organisasjonen eig. PAC-reglar kan gje ulike resultat for interne tenester, offentlege nettstader og failover-tilstandar, og ein regel som passar URL-en din i dag, kan etter ei endring passa ein annan.

Viss arbeidsflyten treng meir enn éin kjend førespurnad, bruk ei statisk innstilling som administratoren støttar, eller ein godkjend PAC-medviten integrasjon. Å hardkoda éi kopiert adresse fungerer til den dagen policyen blir endra og ingen lenger hugsar kvifor den adressa vart vald.

Sjå så på kva curl arvar. Proxy-miljøvariablar og NO_PROXY kan overstyra eller utelukka proxyen du sende, og eit uteluk som passar målet ditt sender førespurnaden direkte utan å seia det. Hald på den tiltenkte policyen i staden for å sletta kvart uteluk eller tvinga alt gjennom éi adresse. Køyr førespurnaden éin gong med -v og sjekk kva for ei adresse han faktisk kopla til.

Hald dei to TLS-identitetane frå kvarandre

Med ein HTTPS-proxy er to TLS-tilkoplingar i spel: di til proxyen og proxyen si til destinasjonen. Kvar har sin eigen identitet å verifisera, og å slå av verifiseringa for ein av dei er ikkje ei PAC-løysing, det er eit andre problem lagt til det første.

Lat verifiseringa stå på og les feilen du får. Ei proxyautentiseringsutfordring, ein utilgjengeleg proxy og ei avvising frå nettstaden er tre ulike resultat, og berre det første handlar om påloggingsinformasjon. VPN-en må framleis gje ein tillaten veg til ein privat proxy, inkludert namneoppslag for proxyverten sjølv, før noko av dette kan lukkast.

Skriv ned endepunktet, skjemaet, porten, autentiseringsmetoden, uteluka og VPN-vegen til proxyen. Den registreringa er det som gjer den neste førespurnaden reproduserbar, og det er skilnaden mellom å kjenna proxyen sin og å gjetta på han.