Правило отправляет http://reports.example:80/ через прокси, но http://reports.example/ пропускает напрямую. Эти URL описывают одну и ту же обычную конечную точку HTTP. Несоответствие обычно возникает из-за буквального сравнения разобранных портов.

URI.getPort() возвращает -1, когда в URI нет порта. Он не подставляет значение по умолчанию для схемы. Политика маршрутизации, сравнивающая значение с 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. Совпадение только хоста и порта не должно заставлять этот обратный вызов возвращать HTTP-прокси, предназначенный для URL-запросов. Передавайте неподдерживаемые схемы предыдущему селектору, сохраняя его надлежащее поведение.

Захватите этот предыдущий селектор до установки своего. Поиск текущего значения по умолчанию изнутри замены может просто снова вызвать замену.

При диагностике несоответствия записывайте схему, хост, исходный порт и фактический порт. Не полагайтесь на одно наблюдаемое число или порядок обратных вызовов в разных реализациях JDK. Политика должна принимать правильное решение для каждого переданного URI.

Похожие статьи