curl no pot llegir el teu fitxer PAC: passa el proxy en lloc seu

L’adreça del fitxer PAC i el punt final del proxy semblen intercanviables en un fitxer de configuració, i no ho són. Un és un programa de política que s’ha d’avaluar per a cada URL; l’altre és un amfitrió i un port que accepta connexions. curl només entén el segon. Passar una adreça PAC a --proxy és un error de categoria que falla d’una manera confusa, normalment després d’una espera CONNECT llarga cap a un servidor web.

Què és realment cadascun

Les preguntes freqüents de curl ho diuen clarament: curl no ofereix interpretació de JavaScript ni de PAC. Un embolcall al voltant de curl que entengui PAC pot fer-ho, però curl mateix no, i cap opció el converteix en un navegador.

Per què el navegador funciona i curl no

Un navegador s’integra amb la configuració de proxy del sistema, baixa el fitxer PAC i executa les seves regles contra l’URL que obriu. Aquesta avaluació és el servei que ofereix el fitxer PAC, i passa dins del navegador, no dins del vostre terminal.

Baixar el fitxer PAC amb curl només n’obté el text. No fa que curl executi la política, i llegir-lo a mà per trobar un proxy és una versió manual de la mateixa avaluació, amb la mateixa possibilitat de triar la branca equivocada. Si el llegiu, llegiu la instrucció return que correspon al vostre amfitrió en lloc del primer nom de proxy del fitxer. La majoria de fitxers PAC en contenen diversos, i només una branca us afecta.

Per a un proxy HTTP aprovat i un servei HTTPS aprovat, una petició il·lustrativa és:

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

La primera adreça és el receptor del proxy, la segona és el servei que voleu. Aquests són punts finals d’exemple, no una prova que ningú hagi fet, així que substituïu-los per l’esquema, el port i el flux d’autenticació de la vostra organització.

Trieu el proxy per a aquesta destinació

Pregunteu a l’administrador quin proxy tria la política per a l’URL que necessiteu, no quin proxy té l’organització. Les regles PAC poden donar resultats diferents per a serveis interns, llocs públics i condicions de commutació per error, i una regla que avui coincideix amb el vostre URL pot coincidir amb una altra després d’una edició.

Si el flux de treball necessita més d’una petició coneguda, feu servir una configuració estàtica que l’administrador admeti o una integració aprovada que entengui PAC. Codificar una sola adreça copiada funciona fins al dia que la política canvia i ningú recorda per què es va triar aquella adreça.

Després mireu què hereta curl. Les variables d’entorn de proxy i NO_PROXY poden substituir o excloure el proxy que heu passat, i una exclusió que coincideixi amb el vostre objectiu envia la petició directament sense avisar. Conserveu la política prevista en lloc de suprimir totes les exclusions o forçar-ho tot per una sola adreça. Executeu la petició una vegada amb -v i comproveu a quina adreça s’ha connectat realment.

Mantingueu les dues identitats TLS separades

Amb un proxy HTTPS, hi ha dues connexions TLS en joc: la vostra cap al proxy i la del proxy cap a la destinació. Cadascuna té la seva pròpia identitat per verificar, i desactivar la verificació d’una d’elles no és una solució PAC, és un segon problema afegit al primer.

Mantingueu la verificació activada i llegiu la fallada que obteniu. Un repte d’autenticació del proxy, un proxy inabastable i una negativa del lloc web són tres resultats diferents, i només el primer tracta de credencials. La VPN encara ha de proporcionar un camí permès cap a un proxy privat, inclosa la resolució de noms per al mateix amfitrió del proxy, abans que res d’això pugui funcionar.

Anoteu el punt final, l’esquema, el port, el mètode d’autenticació, les exclusions i el camí VPN fins al proxy. Aquest registre és el que fa reproduïble la propera petició, i és la diferència entre conèixer el vostre proxy i endevinar-lo.