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

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

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

For 4.5-API-et må begge fabrikkene være med 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 Apache 4s org.apache.http-pakker. Utdraget forutsetter Javas lokale variabeltypeinferens; eldre Java-kildekode kan bruke eksplisitte typer.

Knytt 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 allerede bygget klient.

Undersøk også builderens eierskap: HttpClientBuilder dokumenterer at en eksplisitt levert tilkoblingsbehandler kan overstyre de separate SSL-konfigurasjonsinndataene. Legg de nødvendige fabrikkene i behandlerens register i stedet for å anta at et senere setSSLContext-kall erstatter dets 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.