curl nuk mund të lexojë skedarin tuaj PAC: kalo proxy-n në vend të tij

Adresa e skedarit PAC dhe pika fundore e proxy-t duken të këmbyeshme në një skedar konfigurimi, dhe nuk janë. Njëra është një program politike që duhet vlerësuar për çdo URL; tjetra është një host dhe port që pranon lidhje. curl kupton vetëm të dytën. Kalimi i një adrese PAC te --proxy është një gabim kategorie që dështon në mënyrë ngatërruese, zakonisht pas një afati të gjatë CONNECT drejt një serveri web.

Çfarë është në të vërtetë secili

Këtë e thonë qartë pyetjet e shpeshta për curl: curl nuk ofron asnjë interpretim të JavaScript ose PAC. Një mbështjellës rreth curl që kupton PAC mundet, por vetë curl jo, dhe asnjë flamur nuk e kthen në një shfletues.

Pse shfletuesi funksionon dhe curl jo

Një shfletues integrohet me konfigurimin e proxy-t të sistemit, shkarkon skedarin PAC dhe ekzekuton rregullat e tij ndaj URL-së që hap. Ai vlerësim është shërbimi që ofron skedari PAC, dhe ndodh brenda shfletuesit, jo brenda terminalit tënd.

Shkarkimi i skedarit PAC me curl jep vetëm tekstin e tij. Nuk e bën curl të ekzekutojë politikën, dhe leximi i tij me dorë për të gjetur një proxy është një version me dorë i të njëjtit vlerësim, me të njëjtin shans për të zgjedhur degën e gabuar. Nëse e lexon, lexo deklaratën return që i përshtatet hostit tënd në vend të emrit të parë të proxy-t në skedar. Shumica e skedarëve PAC përmbajnë disa, dhe vetëm një degë vlen për ty.

Për një proxy HTTP të miratuar dhe një shërbim HTTPS të miratuar, një kërkesë ilustruese është:

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

Adresa e parë është dëgjuesi i proxy-t, e dyta është shërbimi që dëshiron. Këto janë pika fundore shembull, jo një test që ka kryer dikush, prandaj zëvendësoji me skemën, portin dhe rrjedhën e vërtetimit të organizatës tënde.

Zgjidh proxy-n për këtë destinacion

Pyet administratorin cilin proxy zgjedh politika për URL-në që të nevojitet, jo cilin proxy zotëron organizata. Rregullat PAC mund të kthejnë rezultate të ndryshme për shërbime të brendshme, sajte publike dhe kushte kalimi për dështim, dhe një rregull që përputhet sot me URL-në tënde mund të përputhet me një tjetër pas një redaktimi.

Nëse rrjedha e punës kërkon më shumë se një kërkesë të njohur, përdor një konfigurim statik të mbështetur nga administratori ose një integrim të miratuar që kupton PAC. Kodimi i fortë i një adrese të kopjuar funksionon deri në ditën kur politika ndryshon dhe askush nuk kujtohet pse u zgjodh ajo adresë.

Më pas shiko çfarë trashëgon curl. Variablat e mjedisit të proxy-t dhe NO_PROXY mund të anashkalojnë ose të përjashtojnë proxy-n që ke kaluar, dhe një përjashtim që përputhet me objektivin tënd e dërgon kërkesën drejtpërdrejt pa e thënë. Ruaj politikën e synuar në vend që të fshish çdo përjashtim ose të detyrosh gjithçka përmes një adrese të vetme. Ekzekuto kërkesën një herë me -v dhe kontrollo me cilën adresë u lidh vërtet.

Mbaji të ndara dy identitetet TLS

Me një proxy HTTPS, janë në lojë dy lidhje TLS: e jotja drejt proxy-t dhe ajo e proxy-t drejt destinacionit. Secila ka identitetin e vet për të verifikuar, dhe çaktivizimi i verifikimit për cilëndo prej tyre nuk është riparim PAC, është një problem i dytë i shtuar të parit.

Lëre verifikimin të ndezur dhe lexo dështimin që merr. Një sfidë vërtetimi e proxy-t, një proxy i paarritshëm dhe një refuzim nga sajti janë tre rezultate të ndryshme, dhe vetëm i pari ka të bëjë me kredencialet. VPN-ja ende duhet të ofrojë një rrugë të lejuar drejt një proxy privat, përfshirë zgjidhjen e emrave për vetë hostin e proxy-t, përpara se ndonjë nga këto të mund të ketë sukses.

Shkruaj pikën fundore, skemën, portin, metodën e vërtetimit, përjashtimet dhe rrugën VPN drejt proxy-t. Ai shënim është ajo që e bën kërkesën tjetër të riprodhueshme, dhe është dallimi midis njohjes së proxy-t tënd dhe hamendjes për të.