Jint PAC 평가: 빠진 헬퍼와 라우트 결과

FindProxyForURL 실행은 한 단계일 뿐이다. 호스트가 PAC 헬퍼를 구현하고 실행을 제한하며 반환된 라우트 목록을 해석해야 한다.

PAC를 평가하는 중 Jint가 없는 dnsResolve 또는 myIpAddress 을 보고한다면, JavaScript를 더 불러오는 것이 반드시 해결책은 아니다. 그 PAC 헬퍼는 호스트 애플리케이션이 제공하는 환경에 속한다.

FindProxyForURL을 호출하기 전에

지원하는 PAC 헬퍼 집합과 주소 체계를 고른 뒤 그 헬퍼를 엔진에 설치한다. 계약을 지켜야 한다. dnsResolve 는 호스트 이름을 받고, myIpAddress 는 인수를 받지 않으며 로컬 인터페이스 정책이 필요하고, shExpMatch 는 셸 스타일 패턴을 쓴다. 편리한 값을 돌려주는 스텁은 조용히 잘못된 라우트를 고를 수 있다.

그 초기화를 마치면 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에서 그렇다. 샘플 결과 하나가 일치한다고 해서 브라우저의 라우팅 동작과 일치한다고 볼 수는 없다.

관련 글