HttpClient 4-proxyfeil: http-protokollen støttes ikke

I en Apache HttpClient 4-applikasjon betyr ikke en HTTPS-destinasjon at hver forbindelse starter med TLS. En vanlig HTTP-proxy nås over en ukryptert forbindelse før CONNECT åpner tunnelen og TLS legges i lag mot destinasjonen.

Hvis en tilpasset forbindelsesbehandler bare registrerer https, kan det første proxyspranget feile med UnsupportedSchemeException: http protocol is not supported.

For 4.5-API-et må begge fabrikkene inkluderes når den behandleren bygges:

var registry = RegistryBuilder.<ConnectionSocketFactory>create()
    .register("http", PlainConnectionSocketFactory.getSocketFactory())
    .register("https", tlsFactory)
    .build();

var manager = new PoolingHttpClientConnectionManager(registry);
var client = HttpClients.custom()
    .setConnectionManager(manager)
    .setProxy(new HttpHost("proxy.example.net", 8080, "http"))
    .build();

tlsFactory er applikasjonens eksisterende SSLConnectionSocketFactory, med den tiltenkte tillits- og vertsnavnkontrollen. Typene som vises, tilhører org.apache.http-pakkene i Apache 4. Utdraget forutsetter Javas lokale variabeltypeinferens; eldre Java-kildekode kan bruke eksplisitte typer.

Fest den korrigerte behandleren til klienten som faktisk brukes for forespørselen. For en tillatt offentlig HTTPS-forespørsel uten proxyautentisering kan en HTTP-oppføring fra HTTP-proxylisten fylle HttpHosts proxyadresse. Å konfigurere en annen builder oppdaterer ikke en klient som allerede er bygget.

Undersøk også eierskapet til builderen: HttpClientBuilder dokumenterer at en eksplisitt levert forbindelsesbehandler kan overstyre de separate SSL-konfigurasjonsinndataene. Legg de nødvendige fabrikkene i behandlerens register i stedet for å anta at et senere setSSLContext-kall erstatter det indre.

Denne diagnosen gjelder det lokale skjemaregisteret. En proxyautentiseringsutfordring eller en avvist destinasjon er et senere, annet resultat. Behold begge fabrikkregistreringene mens du undersøker disse svarene.