Правило надсилає 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.

Схожі статті