Jint による PAC 評価: 不足するヘルパーとルート結果

FindProxyForURL の実行は 1 つの手順にすぎない。ホスト側が PAC ヘルパーを実装し、実行を制限し、返されたルート一覧を解釈する必要がある。

PAC の評価中に Jint が dnsResolve や myIpAddress の不足を報告しても、JavaScript をさらに読み込むことが必ずしも解決策ではない。これらの PAC ヘルパーはホストアプリケーションが提供する環境に属する。

FindProxyForURL を呼ぶ前に

対応する PAC ヘルパーの集合とアドレスファミリーを選び、そのヘルパーをエンジンに登録する。契約を保つこと: dnsResolve はホスト名を受け取り、myIpAddress は引数を取らずローカルインターフェースの方針が必要で、shExpMatch は shell 形式のパターンを使う。都合のよい値を返すスタブは、誤ったルートを黙って選びかねない。

その初期化が済んだら、Jint 4.4.0 では中核の呼び出しは次のようになる。

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

engine は設定済みの Jint.Engine、pacSource は取得した PAC プログラムである。destination.IdnHost はポートもパスも含まないホスト名を渡す。この呼び出しは PAC を取得せず、プロキシ接続も開かない。

呼び出しの後

PROXY proxy.example:8080; DIRECT のような結果は 順序付きのルート候補とフォールバックの一覧 として解釈する。文字列全体をプロキシ URL として渡すと意味を失う。評価の失敗は明示的な DIRECT の結果と区別しておく。

実行中

Jint の実行時間・文数・メモリ・キャンセルの制限を設定し、必要なホスト関数だけを公開する。DNS コールバックは別に制限する: JavaScript 実行の検査は、任意のブロッキングなホスト呼び出しを中断可能にはしない。エンジンへのアクセスは直列化するか、並行処理には別々に所有するインスタンスを与える。エンジンは同時利用に対して安全ではない。

ブラウザの PAC 実装は、ヘルパーの拡張や公開する URL の詳細が異なることがあり、とくに HTTPS で顕著である。1 つのサンプル結果が一致しても、ブラウザのルーティング挙動と一致したことにはならない。

関連記事