HttpClient 4 prokura eraro: http-protokolo ne estas subtenata

En aplikaĵo Apache HttpClient 4, HTTPS-celo ne signifas, ke ĉiu konekto komenciĝas per TLS. Oni atingas ordinaran HTTP-prokuron per senĉifra konekto antaŭ ol CONNECT malfermas la tunelon kaj TLS estas tavoligita al la celo.

Se propra konekta administranto registras nur https, la unua prokura salto povas malsukcesi per UnsupportedSchemeException: http protocol is not supported.

Por la 4.5-API, inkluzivu ambaŭ fabrikojn kiam vi konstruas tiun administranton:

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 estas la ekzistanta SSLConnectionSocketFactory de la aplikaĵo, kun sia celita fido- kaj gastignoma kontrolo. La montritaj tipoj apartenas al la pakaĵoj org.apache.http de Apache 4. La fragmento supozas lokan variablotipan dedukton de Java; pli malnova Java-kodo povas uzi eksplicitajn tipojn.

Ligu la korektitan administranton al la kliento efektive uzata por la peto. Por permesita publika HTTPS-peto sen prokura aŭtentigo, HTTP-ero el la HTTP-prokura listo povas plenigi la prokuran adreson de HttpHost. Agordi alian konstruilon ne ĝisdatigas jam konstruitan klienton.

Ankaŭ ekzamenu la posedon de la konstruilo: HttpClientBuilder dokumentas, ke eksplicite liverita konekta administranto povas superregi ĝiajn apartajn SSL-agordajn enigojn. Metu la bezonatajn fabrikojn en la registron de la administranto anstataŭ supozi, ke posta voko al setSSLContext anstataŭigos ĝiajn internaĵojn.

Ĉi tiu diagnozo koncernas la lokan skemregistron. Prokura aŭtentiga defio aŭ rifuzita celo estas posta, malsama rezulto. Konservu ambaŭ fabrikajn registradojn dum vi esploras tiujn respondojn.