curl kan jou PAC-lêer nie lees nie: gee eerder die proxy deur

Die adres van die PAC-lêer en die proxy-eindpunt lyk in ’n konfigurasielêer uitruilbaar, en hulle is nie. Een is ’n beleidsprogram wat vir elke URL geëvalueer moet word; die ander is ’n gasheer en poort wat verbindings aanvaar. curl verstaan net die tweede. Om ’n PAC-adres aan --proxy te gee is ’n kategorie-fout wat op ’n verwarrende manier misluk, gewoonlik ná ’n lang CONNECT-tydsverloop na ’n webbediener.

Wat elkeen eintlik is

Die curl-FAQ sê dit duidelik: curl bied geen JavaScript- of PAC-interpretasie nie. ’n PAC-bewuste omhulsel rondom curl mag dit doen, maar curl self nie, en geen vlag maak daarvan ’n blaaier nie.

Waarom die blaaier werk en curl nie

’n Blaaier sluit by die stelsel se proxy-konfigurasie aan, haal die PAC-lêer en voer die reëls daarvan uit teen die URL wat jy oopmaak. Daardie evaluering is die diens wat die PAC-lêer lewer, en dit gebeur binne die blaaier, nie binne jou terminaal nie.

Om die PAC-lêer met curl af te laai, kry net die teks daarvan. Dit laat curl nie die beleid uitvoer nie, en om dit met die hand te lees om ’n proxy te vind is ’n handmatige weergawe van dieselfde evaluering, met dieselfde kans om die verkeerde tak te kies. As jy dit wel lees, lees die return-stelling wat by jou gasheer pas, eerder as die eerste proxy-naam in die lêer. Die meeste PAC-lêers bevat verskeie, en net een tak geld vir jou.

Vir ’n goedgekeurde HTTP-proxy en ’n goedgekeurde HTTPS-diens is ’n illustratiewe versoek:

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

Die eerste adres is die proxy-luisteraar, die tweede is die diens wat jy wil hê. Dit is voorbeeld-eindpunte eerder as ’n toets wat iemand uitgevoer het, so vervang dit met jou organisasie se skema, poort en verifikasiewerkvloei.

Kies die proxy vir hierdie bestemming

Vra die administrateur watter proxy die beleid kies vir die URL wat jy nodig het, nie watter proxy die organisasie besit nie. PAC-reëls kan verskillende resultate gee vir interne dienste, openbare werwe en failover-toestande, en ’n reël wat vandag by jou URL pas, kan ná ’n wysiging by ’n ander een pas.

As die werkvloei meer as een bekende versoek nodig het, gebruik ’n administrateur-gesteunde statiese instelling of ’n goedgekeurde PAC-bewuste integrasie. Om een gekopieerde adres hard te kodeer werk tot die dag wanneer die beleid verander en niemand meer onthou hoekom daardie adres gekies is nie.

Kyk dan na wat curl oorneem. Proxy-omgewingsveranderlikes en NO_PROXY kan die proxy wat jy deurgegee het, oorheers of uitsluit, en ’n uitsluiting wat by jou teiken pas, stuur die versoek stilweg direk. Handhaaf die bedoelde beleid eerder as om elke uitsluiting te skrap of alles deur een adres te dwing. Voer die versoek een keer met -v uit en kyk na watter adres dit werklik verbind het.

Hou die twee TLS-identiteite uitmekaar

By ’n HTTPS-proxy is daar twee TLS-verbindings in die spel: joune na die proxy en die proxy se een na die bestemming. Elkeen het sy eie identiteit om te verifieer, en om verificering vir een van hulle af te skakel is nie ’n PAC-oplossing nie, dit is ’n tweede probleem by die eerste.

Hou verificering aan en lees die fout wat jy kry. ’n Proxy-verifikasie-uitdaging, ’n onbereikbare proxy en ’n weiering van die webwerf is drie verskillende resultate, en net die eerste gaan oor geloofsbriewe. Die VPN moet steeds ’n toegelate pad na ’n private proxy verskaf, insluitend naamresolusie vir die proxy-gasheer self, voordat enigiets hiervan kan slaag.

Skryf die eindpunt, skema, poort, verifikasiemetode, uitsluitings en die VPN-pad na die proxy neer. Daardie rekord is wat die volgende versoek herhaalbaar maak, en dit is die verskil tussen jou proxy ken en daaroor raai.