PAC-evaluering i Jint: manglende hjelpere og rutesvar
Å kalle FindProxyForURL er ett trinn: verten må implementere PAC-hjelpere, begrense kjøringen og tolke rute listen som returneres.
Dersom Jint rapporterer at dnsResolve eller myIpAddress mangler under PAC-evalueringen, er ikke nødvendigvis mer JavaScript løsningen. Disse PAC-hjelperne hører til miljøet som vertsapplikasjonen tilbyr.
Før du kaller FindProxyForURL
Velg det støttede settet av PAC-hjelpere og adressefamilier, og installer deretter hjelperne på motoren. Behold 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 praktisk verdi kan i stillhet velge feil rute.
Når den initialiseringen er utført, 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 avbrytelse, og eksponer bare de nødvendige vertsfunksjonene. Begrens DNS-tilbakekall separat: kontroller 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.