En regel sender http://reports.example:80/ gennem en proxy, men lader http://reports.example/ gå direkte. De URL'er beskriver det samme almindelige HTTP-endepunkt. Uoverensstemmelsen kommer normalt af at sammenligne deres parsede porte bogstaveligt.

URI.getPort() returnerer -1, når der ikke står en port i URI'en. Den erstatter ikke standardværdien for skemaet. En routingpolitik, der sammenligner værdien med 80, vil overse den anden 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;
}

Anvend den samme normalisering på begge sider af sammenligningen. Retter du kun anmodningens URI, efterlader det stadig en konfigureret destination med udeladt port uden match. Sammenlign vært, effektiv port og tilsigtet skema; afvis misdannede eller værtsløse destinationer gennem en defineret fejlvej.

Gør ikke hvert callback til en HTTP-beslutning

En standardvælger kan også blive spurgt for rå socket-forbindelser med skemaet socket. Et værts- og portmatch alene må ikke få det callback til at returnere en HTTP-proxy beregnet til URL-anmodninger. Videresend ikke-understøttede skemaer til den forrige vælger og bevar dens passende adfærd.

Fang den forrige vælger, før du installerer din egen. At slå den aktuelle standard op inde fra erstatningen kan blot kalde erstatningen igen.

Log skema, vært, oprindelig port og effektiv port, når du diagnosticerer en uoverensstemmelse. Afhæng ikke af ét observeret tal eller rækkefølgen af callbacks på tværs af JDK-implementeringer. Politikken bør træffe en korrekt beslutning for hver leveret URI.

Relaterede artikler