HttpClient 4 ಪ್ರಾಕ್ಸಿ ದೋಷ: http ಪ್ರೋಟೋಕಾಲ್ ಬೆಂಬಲಿತವಾಗಿಲ್ಲ

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 ಕರೆ ಅದರ ಒಳಭಾಗವನ್ನು ಬದಲಿಸುತ್ತದೆ ಎಂದು ಊಹಿಸುವ ಬದಲು.

ಈ ರೋಗನಿರ್ಣಯ ಸ್ಥಳೀಯ ಸ್ಕೀಮ್ ನೋಂದಣಿಗೆ ಸಂಬಂಧಿಸಿದೆ. ಪ್ರಾಕ್ಸಿ ದೃಢೀಕರಣ ಸವಾಲು ಅಥವಾ ನಿರಾಕರಿಸಿದ ಗಮ್ಯಸ್ಥಾನ ನಂತರದ, ಬೇರೆ ಫಲಿತಾಂಶ. ಆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ತನಿಖೆ ಮಾಡುವಾಗ ಎರಡೂ ಫ್ಯಾಕ್ಟರಿ ನೋಂದಣಿಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳಿ.