នៅក្នុងកម្មវិធី 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 ក្រោយមកនឹងជំនួសខាងក្នុងរបស់វា។

ការធ្វើរោគវិនិច្ឆ័យនេះទាក់ទងនឹងបញ្ជីឈ្មោះគ្រោងការមូលដ្ឋាន។ ការប្រឈមផ្ទៀងផ្ទាត់ប្រូកស៊ី ឬគោលដៅដែលត្រូវបានបដិសេធ គឺជាលទ្ធផលក្រោយមក និងខុសគ្នា។ រក្សាការចុះឈ្មោះរោងចក្រទាំងពីរ ខណៈពេលអ្នកស៊ើបអង្កេតការឆ្លើយតបទាំងនោះ។

អត្ថបទពាក់ព័ន្ធ