В приложение с Apache HttpClient 4 HTTPS дестинация не означава, че всяка връзка започва с TLS. До обикновено HTTP прокси се стига по незащифрована връзка, преди CONNECT да отвори тунела и TLS да се насложи към дестинацията.

Ако собствен мениджър на връзки регистрира само https, първият прескок през прокси може да се провали с UnsupportedSchemeException: http protocol is not supported.

За API 4.5 включете и двете фабрики при изграждането на този мениджър:

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 е съществуващата SSLConnectionSocketFactory на приложението с предвидената проверка на доверие и име на хост. Показаните типове принадлежат на пакетите org.apache.http на Apache 4. Фрагментът предполага извеждане на типове на локални променливи в Java; по-стар Java код може да използва явни типове.

Прикачете коригирания мениджър към клиента, който действително се използва за заявката. За разрешена публична HTTPS заявка без удостоверяване на прокси HTTP запис от списъка с HTTP прокси може да запълни адреса на прокси в HttpHost. Конфигурирането на друг builder не обновява вече създаден клиент.

Проверете и собствеността на builder: HttpClientBuilder документира, че изрично подаден мениджър на връзки може да отмени отделните му входове за SSL конфигурация. Поставете нужните фабрики в регистъра на мениджъра, вместо да предполагате, че по-късно извикване на setSSLContext ще замени вътрешностите му.

Тази диагностика се отнася до локалния регистър на схеми. Предизвикателство за удостоверяване на прокси или отказана дестинация е по-късен, различен резултат. Запазете и двете регистрации на фабрики, докато изследвате тези отговори.

Подобни статии