O regulă trimite http://reports.example:80/ printr-un proxy, dar lasă http://reports.example/ să meargă direct. Acele URL-uri descriu același punct final HTTP obișnuit. Neconcordanța provine de obicei din compararea literală a porturilor analizate.

URI.getPort() returnează -1 când în URI nu apare niciun port. Nu înlocuiește valoarea implicită a schemei. O politică de rutare care compară valoarea cu 80 va rata al doilea 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;
}

Aplicați aceeași normalizare pe ambele părți ale comparației. Corectarea doar a URI-ului cererii lasă în continuare o destinație configurată cu port omis fără potrivire. Comparați gazda, portul efectiv și schema dorită; respingeți destinațiile malformate sau fără gazdă printr-o cale de eroare definită.

Nu transformați fiecare apel invers într-o decizie HTTP

Un selector implicit poate fi consultat și pentru conexiuni de socketuri brute, cu schema socket. Doar potrivirea gazdă-port nu trebuie să facă acel apel invers să returneze un proxy HTTP destinat cererilor URL. Delegați schemele neacceptate selectorului anterior, păstrând comportamentul său adecvat.

Capturați acel selector anterior înainte de a-l instala pe al dumneavoastră. Căutarea valorii implicite curente din interiorul înlocuitorului poate apela pur și simplu din nou înlocuitorul.

Înregistrați schema, gazda, portul original și portul efectiv când diagnosticați o neconcordanță. Nu vă bazați pe un singur număr observat sau pe ordinea apelurilor inverse între implementările JDK. Politica ar trebui să ia o decizie corectă pentru fiecare URI furnizat.

Articole similare