Om Jint rapporterar att dnsResolve eller myIpAddress saknas vid utvärdering av PAC är det inte säkert att mer JavaScript är lösningen. Dessa PAC-hjälpare tillhör den miljö som värdapplikationen tillhandahåller.

Innan FindProxyForURL anropas

Välj den PAC-hjälparuppsättning och de adressfamiljer som stöds och installera sedan hjälparna i motorn. Behåll deras kontrakt: dnsResolve tar ett värdnamn, myIpAddress tar inga argument och kräver en policy för lokalt gränssnitt, och shExpMatch använder mönster i skalstil. En stub som returnerar ett bekvämt värde kan tyst välja fel rutt.

När den initieringen är gjord kan kärnanropet se ut så här i Jint 4.4.0:

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

engine är den konfigurerade Jint.Engine; pacSource är det hämtade PAC-programmet. destination.IdnHost ger värdnamnet utan port eller sökväg. Detta anrop hämtar inte PAC och öppnar ingen proxyanslutning.

Efter anropet

Tolka ett resultat som PROXY proxy.example:8080; DIRECT som en ordnad lista över ruttkandidater och reserv. Att skicka hela strängen som en proxy-URL förlorar dess betydelse. Håll ett utvärderingsfel skilt från ett uttryckligt DIRECT-resultat.

Medan det körs

Konfigurera Jints begränsningar för varaktighet, utsagor, minne och avbrott och exponera endast de värd­funktioner som behövs. Begränsa DNS-återanrop separat: kontroller av JavaScript-körning gör inte ett godtyckligt blockerande värdanrop avbrytbart. Serialisera åtkomsten till en motor eller ge samtidigt arbete separat ägda instanser; motorer är inte säkra för samtidig användning.

Webbläsares PAC-implementeringar kan skilja sig i hjälparutökningar och i de URL-detaljer de exponerar, särskilt för HTTPS. Att matcha ett provresultat bevisar mindre än att matcha webbläsarens routingbeteende.

Relaterade artiklar