[筆記] Apache HTTP Client 5 的注意事項

• 要控制 timeout，應該使用的是 RequestConfig 裡的 connectTimeout，而不是 responseTimeout。
• responseTimeout 從原始碼來看，跟 socketTimeout 是差不多的東西。
• socketTimeout 代表的意思是距離上一次 network I/O 的時間差。也就是說，如果設定 socketTimeout 為 nms，則每 n-1 ms 收到一個封包，也是不會觸發 timeout 的。

​

Java 的 SSL 驗證

一般在 Java 要存取 HTTPS 的服務的時候，大多數狀況因為常見的 CA 應該都已經列在 JRE 的 cacerts（CA Certification 檔）裡了，所以通常不會遇到什麼問題。不過如果遇到要存取的是像是公司內部的服務，公司自己有自己的 CA 時，可能就得做點事情來讓 HTTPS 的 SSL/TLS 能夠正常運作。

概念上來說，當一個客戶端要存取 HTTPS 的服務時，客戶端只會相信它相信的對象。而要如何決定要相信誰？方法就是客戶端自己會存放一個信任的 CA 的清單，如果發現 HTTPS 服務的憑證是由信任的 CA 所發放的、並且憑證所保護的對象也確實是現在存取的對象，那客戶端就會相信這個 HTTPS 服務。以 Java 的狀況來說，客戶端指的是 JRE，JRE 內建的信任 CA 的清單會是 $JAVA_HOME/lib/security/cacerts 這個檔案。如果沒有特別指定的話，Java 程式在存取 HTTPS 時，進行 SSL/TLS 三方握手時就會以 JRE 內建的 cacerts 來決定對方是否能夠信任。

不過現實上，CA 還會分成 Root Certificate 和 Intermediate Certificate，例如 [1] 的範例一樣：

這裡 Entrust.net Secure Server CA 是 Root Certificate，DigiCert High Assurance EV Root CA 和 DigiCert High Assurance CA-3 則都是 Intermediate Certificate，最後 *.atlassian.com 這個網域的憑證是由 DigiCert High Assurance CA-3 所簽發的。客戶端若要驗證 *.atlassian.com 的憑證，它必須要信任上面的所有 CA（也稱為 Certificate Chain）才行。

HttpClient 在重複不斷存取相同的 URL 時持續 timeout 的問題

做個記錄，寫了一段會一直重複下載同樣一群 RSS 網頁的程式碼
在測試時發現寫的程式碼第一次執行時正常、第二次執行到一半開始一直 timeout
但關掉程式再重新啟動時，第一次又恢復正常，然後一樣第二次差不多地方開始一直 timeout
存取其他不同網址的網頁時則好像沒問題～
最後發現是因為程式碼在最後忘了把 CloseableHttpResponse 關掉（即呼叫 close() 函式）。

java.lang.NoClassDefFoundError: org/apache/http/ssl/TrustStrategy

在使用 Apache HttpClient 時，遇到一個找不到 TrustStrategy 的問題
根據 [1] 的解答，問題是發生在我用 Maven 引入了新版的 httpclient 4.5.1，但是沒有指定 httpcore 的版本
所以 Maven 自動用了比較舊版的 httpcore 4.3.x，導致了找不到需要的類別的問題。

在 Apache HttpClient 4.5 版忽略 HTTPS 認證

一般 HTTPS 連線會驗證包括證書本身以及像是 host name 等資訊
不過在測試階段時，有時會因為證書是用自我驗證來產生的，導致程式碼無法正常運作
HttpClient 有設定方法可以忽略這些認證資訊～
不過在 HttpClient 4.3 版以後，陸續有些類別和方法都被廢棄了
以下是在 HttpClient 4.5 版的設定方法。

使用 Apache HttpClient 4.3 發送 HTTPS 要求時略過所有認證檢查

一般正常在發送 HTTPS 要求時，必須先匯入伺服器的認證，才能正常建立 HTTPS 的加密連線
但某些狀況下，伺服器使用自我認證等等的方式時，會想要略過這些認證檢查（把 HTTPS 當成 HTTP 在使用...XD）
在 Apache HttpClient 4.3 當中可以用以下的方式取得 HTTPS 的連線。