curl nu poate citi fișierul PAC: transmite proxy-ul în schimb

Adresa fișierului PAC și punctul final al proxy-ului par interschimbabile într-un fișier de configurare, dar nu sunt. Unul este un program de politică ce trebuie evaluat pentru fiecare URL; celălalt este un host și un port care acceptă conexiuni. curl înțelege doar al doilea. Transmiterea unei adrese PAC către --proxy este o eroare de categorie care eșuează într-un mod confuz, de obicei după un timp de așteptare CONNECT lung către un server web.

Ce este de fapt fiecare

Acest lucru este spus clar de întrebările frecvente despre curl: curl nu oferă nicio interpretare de JavaScript sau PAC. Un înveliș în jurul curl care înțelege PAC poate, dar curl în sine nu, și nicio opțiune nu îl transformă într-un browser.

De ce browserul funcționează, iar curl nu

Un browser se integrează cu configurația de proxy a sistemului, descarcă fișierul PAC și rulează regulile acestuia pentru URL-ul pe care îl deschizi. Această evaluare este serviciul oferit de fișierul PAC și are loc în interiorul browserului, nu în terminalul tău.

Descărcarea fișierului PAC cu curl obține doar textul acestuia. Nu îl face pe curl să execute politica, iar citirea lui manuală pentru a găsi un proxy este o versiune manuală a aceleiași evaluări, cu aceeași șansă de a alege ramura greșită. Dacă îl citești, citește instrucțiunea return care corespunde hostului tău, nu primul nume de proxy din fișier. Majoritatea fișierelor PAC conțin mai multe, iar doar o ramură ți se aplică.

Pentru un proxy HTTP aprobat și un serviciu HTTPS aprobat, o cerere ilustrativă este:

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

Prima adresă este ascultătorul proxy-ului, a doua este serviciul dorit. Acestea sunt puncte finale exemplificative, nu un test efectuat de cineva, așa că înlocuiește-le cu schema, portul și fluxul de autentificare ale organizației tale.

Alege proxy-ul pentru această destinație

Întreabă administratorul ce proxy alege politica pentru URL-ul de care ai nevoie, nu ce proxy deține organizația. Regulile PAC pot returna rezultate diferite pentru servicii interne, site-uri publice și stări de comutare la defecțiune, iar o regulă care se potrivește astăzi URL-ului tău poate corespunde altuia după o editare.

Dacă fluxul de lucru are nevoie de mai mult de o cerere cunoscută, folosește o setare statică acceptată de administrator sau o integrare aprobată care înțelege PAC. Codificarea fixă a unei singure adrese copiate funcționează până în ziua în care politica se schimbă și nimeni nu își mai amintește de ce a fost aleasă acea adresă.

Apoi uită-te la ce moștenește curl. Variabilele de mediu pentru proxy și NO_PROXY pot suprascrie sau exclude proxy-ul transmis, iar o excludere care corespunde țintei tale trimite cererea direct, fără să spună nimic. Păstrează politica intenționată în loc să ștergi fiecare excludere sau să forțezi totul printr-o singură adresă. Rulează cererea o dată cu -v și verifică la ce adresă s-a conectat de fapt.

Ține cele două identități TLS separate

Cu un proxy HTTPS, sunt în joc două conexiuni TLS: a ta către proxy și a proxy-ului către destinație. Fiecare are propria identitate de verificat, iar dezactivarea verificării pentru oricare dintre ele nu este o remediere PAC, ci o a doua problemă adăugată primeia.

Lasă verificarea activă și citește eșecul pe care îl primești. O provocare de autentificare a proxy-ului, un proxy inaccesibil și un refuz din partea site-ului sunt trei rezultate diferite, iar doar primul ține de acreditări. VPN-ul trebuie în continuare să ofere o cale permisă către un proxy privat, inclusiv rezolvarea numelor pentru hostul proxy-ului însuși, înainte ca ceva din toate acestea să reușească.

Notează punctul final, schema, portul, metoda de autentificare, excluderile și calea VPN către proxy. Acea notă este ceea ce face următoarea cerere reproductibilă și este diferența dintre a-ți cunoaște proxy-ul și a ghici despre el.