Apache HttpClient 4 հավելվածում HTTPS նպատակակետը չի նշանակում, որ յուրաքանչյուր կապ սկսվում է TLS-ով։ Սովորական HTTP պրոքսիին հասնում են չգաղտնագրված կապով, նախքան CONNECT-ը կբացի թունելը և TLS-ը կշերտավորվի դեպի նպատակակետը։

Եթե հատուկ կապերի կառավարիչը գրանցում է միայն https, ապա պրոքսիի առաջին ցատկը կարող է ձախողվել UnsupportedSchemeException: http protocol is not supported-ով։

4.5 API-ի համար այդ կառավարիչը կառուցելիս ներառեք երկու գործարանները.

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-ն է՝ իր նախատեսված վստահության և հոսթի անվան ստուգմամբ։ Ցուցադրված տիպերը պատկանում են Apache 4-ի org.apache.http փաթեթներին։ Այս հատվածը ենթադրում է Java-ի լոկալ փոփոխականների տիպերի եզրակացում. ավելի հին Java կոդը կարող է օգտագործել բացահայտ տիպեր։

Ուղղված կառավարիչը կցեք այն կլիենտին, որն իրականում օգտագործվում է հարցման համար։ Առանց պրոքսի նույնականացման թույլատրված հանրային HTTPS հարցման համար HTTP պրոքսիների ցանկից HTTP գրառումը կարող է լրացնել HttpHost-ի պրոքսի հասցեն։ Այլ builder կարգավորելը չի թարմացնում արդեն կառուցված կլիենտը։

Ստուգեք նաև builder-ի սեփականությունը. HttpClientBuilder-ը փաստագրում է, որ բացահայտ տրամադրված կապերի կառավարիչը կարող է վերացնել նրա առանձին SSL կարգավորման մուտքերը։ Տեղադրեք անհրաժեշտ գործարանները կառավարչի ռեեստրում՝ փոխարենը ենթադրելու, որ ավելի ուշ setSSLContext կանչը կփոխարինի նրա ներքինը։

Այս ախտորոշումը վերաբերում է լոկալ սխեմաների ռեեստրին։ Պրոքսի նույնականացման մարտահրավերը կամ մերժված նպատակակետը ավելի ուշ, այլ արդյունք է։ Պահեք երկու գործարանների գրանցումները՝ այդ պատասխանները քննելիս։

Առնչվող հոդվածներ