Egy Apache HttpClient 4 alkalmazásban az HTTPS-cél nem jelenti azt, hogy minden kapcsolat TLS-sel kezdődik. Egy közönséges HTTP-proxyt titkosítatlan kapcsolaton érünk el, mielőtt a CONNECT megnyitja az alagutat, és a TLS a cél felé rétegeződik.

Ha egy egyéni kapcsolatkezelő csak https-t regisztrál, az első proxyugrás UnsupportedSchemeException: http protocol is not supported hibával meghiúsulhat.

A 4.5 API esetében mindkét gyárat vegye fel a kezelő felépítésekor:

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();

A tlsFactory az alkalmazás meglévő SSLConnectionSocketFactoryja, a szándékolt bizalmi és hosztnév-ellenőrzéssel. A bemutatott típusok az Apache 4 org.apache.http csomagjaihoz tartoznak. A részlet feltételezi a Java helyi változóinak típuskövetkeztetését; a régebbi Java-kód kifejezett típusokat használhat.

Csatolja a javított kezelőt ahhoz a klienshez, amelyet a kéréshez ténylegesen használnak. Egy engedélyezett nyilvános HTTPS-kéréshez proxyhitelesítés nélkül a HTTP-proxy listából származó HTTP-bejegyzés kitöltheti a HttpHost proxycímét. Egy másik builder beállítása nem frissít egy már felépített klienst.

Vizsgálja meg a builder tulajdonjogát is: a HttpClientBuilder dokumentálja, hogy egy kifejezetten megadott kapcsolatkezelő felülírhatja annak külön SSL-konfigurációs bemeneteit. Tegye a szükséges gyárakat a kezelő névjegyzékébe, ahelyett hogy feltételezné, egy későbbi setSSLContext hívás lecseréli a belső részeit.

Ez a diagnózis a helyi sémanévjegyzéket érinti. A proxyhitelesítési kihívás vagy az elutasított cél későbbi, más eredmény. Őrizze meg mindkét gyárregisztrációt, miközben ezeket a válaszokat vizsgálja.

Kapcsolódó cikkek