PAC-evaluering i Jint: manglende hjelpere og rutesvar
Å kalle FindProxyForURL er ett trinn: verten må implementere PAC-hjelpere, begrense kjøringen og tolke rutenettlisten som returneres.
Hvis Jint rapporterer at dnsResolve eller myIpAddress mangler under PAC-evaluering, er det ikke sikkert at mer JavaScript er løsningen. Disse PAC-hjelperne tilhører miljøet som vertsprogrammet stiller til rådighet.
Før du kaller FindProxyForURL
Velg det støttede settet med PAC-hjelpere og adressefamilier, og installer deretter hjelperne i motoren. Bevar kontraktene deres: dnsResolve tar et vertsnavn, myIpAddress tar ingen argumenter og trenger en policy for lokalt grensesnitt, og shExpMatch bruker mønstre i skallstil. En stub som returnerer en bekvem verdi kan i stillhet velge feil rute.
Når den initialiseringen er gjort, kan kjernekallet se slik ut i Jint 4.4.0:
var destination = new Uri(destinationUrl);
engine.Execute(pacSource);
var routeList = engine.Invoke(
"FindProxyForURL",
destinationUrl,
destination.IdnHost
).AsString();engine er den konfigurerte Jint.Engine; pacSource er det hentede PAC-programmet. destination.IdnHost gir vertsnavnet uten port eller sti. Dette kallet henter ikke PAC og åpner ikke en proxyforbindelse.
Etter kallet
Tolk et resultat som PROXY proxy.example:8080; DIRECT som en ordnet liste over rutekandidater og reserve. Å sende hele strengen som en proxy-URL mister betydningen. Hold en evalueringsfeil atskilt fra et eksplisitt DIRECT-resultat.
Mens det kjører
Konfigurer Jints begrensninger for varighet, utsagn, minne og avbrudd, og eksponer bare de nødvendige vertsfunksjonene. Begrens DNS-tilbakekall separat: sjekker av JavaScript-kjøring gjør ikke et vilkårlig blokkerende vertskall avbrytbart. Serialiser tilgangen til en motor eller gi samtidig arbeid egne instanser; motorer er ikke trygge for samtidig bruk.
Nettleseres PAC-implementasjoner kan variere i hjelperutvidelser og URL-detaljene de eksponerer, spesielt for HTTPS. Å matche ett prøveresultat beviser mindre enn å matche nettleserens rutingatferd.