I ein Apache HttpClient 4-applikasjon tyder ikkje ein HTTPS-destinasjon at kvar tilkopling startar med TLS. Ein vanleg HTTP-proxy nåast over ei ukryptert tilkopling før CONNECT opnar tunnelen og TLS vert lagt lagvis mot destinasjonen.

Viss ein tilpassa tilkoplingshandsamar berre registrerer https, kan det første proxyspranget mislukkast med UnsupportedSchemeException: http protocol is not supported.

For 4.5-API-et må begge fabrikkane vere med når den handsamaren vert bygd:

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 den eksisterande SSLConnectionSocketFactory-en til applikasjonen, med den tiltenkte tillits- og vertsnamnkontrollen. Typane som vert viste, høyrer til org.apache.http-pakkane i Apache 4. Utdraget føreset lokal variabeltypeinferens i Java; eldre Java-kjeldekode kan bruke eksplisitte typar.

Knyt den retta handsamaren til klienten som faktisk vert brukt for førespurnaden. For ein tillaten offentleg HTTPS-førespurnad utan proxyautentisering kan ein HTTP-oppføring frå HTTP-proxylista fylla proxyadressa til HttpHost. Å konfigurere ein annan builder oppdaterer ikkje ein klient som alt er bygd.

Undersøk òg eigarskapen til builderen: HttpClientBuilder dokumenterer at ein eksplisitt levert tilkoplingshandsamar kan overstyre dei separate SSL-konfigurasjonsinndataa. Legg dei naudsynte fabrikkane i registeret til handsamaren i staden for å gå ut frå at eit seinare setSSLContext-kall erstattar det indre.

Denne diagnosen gjeld det lokale skjemaregisteret. Ei proxyautentiseringsutfordring eller ein avvist destinasjon er eit seinare, anna resultat. Hald på begge fabrikkregistreringane medan du granskar desse svara.

Relaterte artiklar