Jint PAC Evaluation: Missing Helpers and Route Results

If Jint reports a missing dnsResolve or myIpAddress while evaluating PAC, loading more JavaScript is not necessarily the fix. Those PAC helpers belong to the environment supplied by the host application.

Before calling FindProxyForURL

Choose the supported PAC helper set and address families, then install those helpers on the engine. Preserve their contracts: dnsResolve takes a hostname, myIpAddress takes no arguments and needs a local-interface policy, and shExpMatch uses shell-style patterns. A stub returning a convenient value can silently choose the wrong route.

With that initialization done, the core call can look like this in Jint 4.4.0:

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

engine is the configured Jint.Engine; pacSource is the retrieved PAC program. destination.IdnHost supplies the hostname without a port or path. This call neither retrieves PAC nor opens a proxy connection.

After the call

Interpret a result such as PROXY proxy.example:8080; DIRECT as an ordered list of route candidates and fallback. Passing that whole string as a proxy URL loses its meaning. Keep an evaluation failure distinct from an explicit DIRECT result.

While it runs

Configure Jint's duration, statement, memory and cancellation constraints, and expose only the required host functions. Bound DNS callbacks separately: JavaScript execution checks do not make an arbitrary blocking host call interruptible. Serialize access to an engine or give concurrent work separately owned instances; engines are not safe for simultaneous use.

Browser PAC implementations can differ in helper extensions and the URL details they expose, especially for HTTPS. Matching one sample result establishes less than matching the browser's routing behavior.