Pravidlo posílá http://reports.example:80/ přes proxy, ale http://reports.example/ nechává jít přímo. Tyto URL popisují stejný běžný koncový bod HTTP. Neshoda obvykle vzniká doslovným porovnáním parsovaných portů.

URI.getPort() vrací -1, když v URI není žádný port. Nedosazuje výchozí hodnotu podle schématu. Směrovací politika, která hodnotu porovnává s 80, druhou URL mine.

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

Použijte stejnou normalizaci na obě strany porovnání. Oprava jen URI požadavku stále nechává nakonfigurovaný cíl s vynechaným portem bez shody. Porovnávejte hostitele, efektivní port a zamýšlené schéma; odmítejte poškozené cíle nebo cíle bez hostitele definovanou chybovou cestou.

Nepřevádějte každé volání na rozhodnutí o HTTP

Výchozí selektor lze konzultovat i pro připojení surových socketů, se schématem socket. Shoda hostitele a portu sama nesmí způsobit, že toto volání vrátí proxy HTTP určenou pro URL požadavky. Nepodporovaná schémata předejte předchozímu selektoru a zachovejte jeho vhodné chování.

Zachyťte tento předchozí selektor dřív, než nainstalujete svůj. Zjišťování aktuální výchozí hodnoty zevnitř náhrady může jednoduše znovu zavolat náhradu.

Při diagnostice neshody zaznamenejte schéma, hostitele, původní port a efektivní port. Nespoléhejte na jedno pozorované číslo ani pořadí volání napříč implementacemi JDK. Politika má pro každé dodané URI rozhodnout správně.

Související články