URLConnection從HTTP重定向到HTTPS

　　也不知什麼原因，公司專案的服務端一直在吸引著大波攻擊，於是服務端的同學打算把所有HTTP的請求都換為HTTPS，他們決定相容舊版本於是就將之前的所有HTTP請求全部重定向到另一個HTTPS請求。
專案請求框架搭建初期，考慮到應用也不會使用太複雜的請求模式，於是就簡單使用URLConnection完成服務端互動。服務端一修改，全部請求都失敗了。雖然URLConnection有是否遵循重定向開關（setInstanceFollowRedirects），其預設就是開啟的，即便你再強制其開啟，也是沒有用，問題依舊。找了大量資料，其實問題的關鍵點不是重定向而是從HTTP重定向到HTTPS，關鍵點就在URLConnection的兩個子類上。

HttpURLConnection與HttpsURLConnection

　　HttpURLConnection為URLConnection的子類，而HttpsURLConnection為HttpURLConnection的子類，在HttpURLConnection基礎上對HTTPS進行支援。
URLConnection通常使用URL的openConnection()方法獲得，而URL是根據其是否為Https開頭來開啟一個HttpURLConnection還是HttpsURLConnection。
而當URLConnection進行connect()時，遇到了重定向，如果打開了遵循重定向，那麼其會獲取重定向的地址，然後嘗試連線這個地址。值得注意的是，這時候並不是使用新的連結地址重新openConnection()一個URLConnection，而是直接嘗試連線這個重定向的地址，否則也就不存在以上的Bug了。
於是理論上分析，HTTP重定向到HTTP是不存在問題的，HTTPS重定向到HTTPS也是不存在問題的，而HTTP與HTTPS之間的重定向，那麼就很可能會有問題了。HTTP重定向到HTTPS，URLConnection會將重定向的HTTPS以HTTP方式繼續提交，那麼服務端肯定是認為你是錯誤的提交方式；同理，HTTPS重定向HTTP也一樣。

問題解決

• 使用URLConnection抓取到重定向，就使用重定向的地址重新人為openConnection()一個新的URLConnection重新請求。

• 使用第三方請求框架，如OKHttp。

  　　具體專案具體分析，方法一是可行的，但是處理起來就很麻煩了。而方案二則更可選，因為URLConnection與OKHttp用法其實差不了多遠。