Java ProxySelector: Normaleer ontbrekende HTTP- en HTTPS-poste

Normaliseer weggelate HTTP-poste voordat jy bestemmings in 'n pasgemaakte ProxySelector vergelyk, en hou HTTP-reels uit rou socket-seleksie.

'n Reel stuur http://reports.example:80/ deur 'n proxy, maar laat http://reports.example/ direk gaan. Daardie URL's beskryf dieselfde gewone HTTP-eindpunt. Die wanaanpassing kom gewoonlik daarvan dat hulle ontlede poorte letterlik vergelyk word.

URI.getPort() gee -1 terug wanneer geen poort in die URI voorkom nie. Dit vervang nie die verstekwaarde vir die skema nie. 'n Roetebeleid wat die waarde met 80 vergelyk, sal die tweede URL mis.

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

Pas dieselfde normalisering op beide kante van die vergelyking toe. As jy net die versoek-URI regmaak, bly 'n gekonfigureerde bestemming met 'n weggelate poort steeds onopgelos. Vergelyk die gasheer, die effektiewe poort en die bedoelde skema; verwerp misvormde of gasheerlose bestemmings deur 'n gedefinieerde foutpad.

Moenie elke terugroep in 'n HTTP-besluit verander nie

'n Verstekselektor kan ook vir rou socket-verbindings geraadpleeg word, met die socket-skema. 'n Ooreenkoms op gasheer en poort alleen mag nie veroorsaak dat daardie terugroep 'n HTTP-proxy terugstuur wat vir URL-versoeke bedoel is nie. Delegeer onondersteunde skemas na die vorige selektor en behou sy gepaste gedrag.

Neem daardie vorige selektor waar voordat jy jou pasgemaakte een installeer. Om die huidige verstek van binne die plaasvervanger op te soek, kan eenvoudig die plaasvervanger weer aanroep.

Teken die skema, gasheer, oorspronklike poort en effektiewe poort aan wanneer jy 'n wanaanpassing ondersoek. Moenie op een waargenome getal of volgorde van terugroepe oor JDK-implementasies heen staatmaak nie. Die beleid moet vir elke verskafde URI 'n korrekte besluit neem.

Verwante artikels