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 გამოძახება შეცვლის მის შიდა ნაწილს.

ეს დიაგნოზი ლოკალურ სქემების რეესტრს ეხება. პროქსის ავთენტიფიკაციის გამოწვევა ან უარყოფილი დანიშნულება უფრო გვიანდელი, განსხვავებული შედეგია. შეინარჩუნეთ ორივე ფაბრიკის რეგისტრაცია ამ პასუხების გამოკვლევისას.

დაკავშირებული სტატიები