Java ProxySelector: 누락된 HTTP 및 HTTPS 포트 정규화

사용자 정의 ProxySelector에서 대상을 비교하기 전에 생략된 HTTP 포트를 정규화하고, HTTP 규칙을 원시 소켓 선택에서 배제하세요.

한 규칙은 http://reports.example:80/ 을(를) 프록시로 보내지만 http://reports.example/ 은(는) 직접 통과시킵니다. 두 URL은 같은 일반 HTTP 엔드포인트를 나타냅니다. 불일치는 보통 파싱된 포트를 문자 그대로 비교해서 생깁니다.

URI.getPort() 은(는) URI에 포트가 없으면 -1 을(를) 반환합니다. 스킴의 기본값을 대신 채우지 않습니다. 값을 80과 비교하는 라우팅 정책은 두 번째 URL을 놓칩니다.

String scheme = uri.getScheme();
int port = uri.getPort();
if (port == -1) {
    if ("http".equalsIgnoreCase(scheme)) port = 80;
    else if ("https".equalsIgnoreCase(scheme)) port = 443;
}

비교의 양쪽에 같은 정규화를 적용하세요. 요청 URI만 고치면 포트가 생략된 구성 대상은 여전히 일치하지 않습니다. 호스트, 실효 포트, 의도한 스킴을 비교하고, 잘못되었거나 호스트가 없는 대상은 정의된 오류 경로로 거부하세요.

모든 콜백을 HTTP 결정으로 만들지 마세요

기본 선택자는 socket 스킴을 사용하는 원시 소켓 연결에 대해서도 조회될 수 있습니다. 호스트와 포트가 일치한다는 것만으로 그 콜백이 URL 요청용 HTTP 프록시를 반환해서는 안 됩니다. 지원하지 않는 스킴은 이전 선택자에 위임하고 그 적절한 동작을 유지하세요.

사용자 정의 선택자를 설치하기 전에 그 이전 선택자를 잡아 두세요. 대체자 내부에서 현재 기본값을 조회하면 대체자를 다시 호출할 뿐일 수 있습니다.

불일치를 진단할 때 스킴, 호스트, 원래 포트, 실효 포트를 기록하세요. JDK 구현 간에 관찰된 하나의 숫자나 콜백 순서에 의존하지 마세요. 정책은 주어진 각 URI에 대해 올바른 결정을 내려야 합니다.

관련 글