Jint PAC -arviointi: puuttuvat apurit ja reittitulokset

Jos Jint ilmoittaa puuttuvasta dnsResolve- tai myIpAddress-apurista PAC-arvioinnin aikana, lisä-JavaScriptin lataaminen ei välttämättä ole ratkaisu. Ne PAC-apurit kuuluvat ympäristöön, jonka isäntäsovellus tarjoaa.

Ennen kuin FindProxyForURL kutsutaan

Valitse tuettu PAC-apurijoukko ja osoiteperheet ja asenna apurit sitten moottoriin. Säilytä niiden sopimukset: dnsResolve ottaa isäntänimen, myIpAddress ei ota argumentteja ja vaatii paikallisen liitännän käytännön, ja shExpMatch käyttää shell-tyylisiä kuvioita. Kätevän arvon palauttava tynkä voi valita väärän reitin hiljaa.

Kun alustus on tehty, ydin kutsu voi näyttää tältä Jint 4.4.0:ssa:

var destination = new Uri(destinationUrl);
engine.Execute(pacSource);
var routeList = engine.Invoke(
    "FindProxyForURL",
    destinationUrl,
    destination.IdnHost
).AsString();

engine on määritetty Jint.Engine; pacSource on haettu PAC-ohjelma. destination.IdnHost antaa isäntänimen ilman porttia tai polkua. Tämä kutsu ei hae PAC:ia eikä avaa välityspalvelinyhteyttä.

Kutsun jälkeen

Tulkitse tulos kuten PROXY proxy.example:8080; DIRECT järjestetyksi luetteloksi reittiehdokkaista ja varavaihtoehdosta. Koko merkkijonon välittäminen välityspalvelimen URL:na kadottaa sen merkityksen. Pidä arviointivirhe erillään eksplisiittisestä DIRECT-tuloksesta.

Suorituksen aikana

Määritä Jintin kesto-, lause-, muisti- ja peruutusrajoitukset ja paljasta vain tarvittavat isäntäfunktiot. Rajaa DNS-takaisinkutsut erikseen: JavaScriptin suorituksen tarkistukset eivät tee mielivaltaisesta estävästä isäntäkutsusta keskeytettävää. Sarjallista pääsy moottoriin tai anna rinnakkaiselle työlle erikseen omistetut ilmentymät; moottorit eivät ole turvallisia samanaikaiseen käyttöön.

Selainten PAC-toteutukset voivat erota apurilaajennuksissa ja paljastamissaan URL-tiedoissa, erityisesti HTTPS:n osalta. Yhden näytetuloksen täsmääminen todistaa vähemmän kuin selaimen reitityskäyttäytymisen täsmääminen.