問題描述

在某個地區(qū) DNS被污染的前提下，業(yè)務(wù)側(cè)希望webView也可以通過走cronet長連接（ip直連）+gslb來跳過local dns那一步，但后續(xù)實(shí)施的時候發(fā)現(xiàn)某個webView頁面下的某些js請求響應(yīng)碼雖然是200，但是卻沒有接收到任何數(shù)據(jù)內(nèi)容，前端頁面提示接口請求異常。

雙端差異

上面都是走cronet和長連接的訪問，為啥ios沒問題而android有問題呢？和同事重現(xiàn)下路徑發(fā)現(xiàn)，ios那邊是在web.xx.com下面用sapi.xx.com去發(fā)起接口請求，是沒有Options方法發(fā)起的，但是android的webView下的web.xx.com頁面下的每個sapi.xx.com每次Get/Post請求都會發(fā)起Options請求，和業(yè)務(wù)服務(wù)求助該sapi.xx.com資源請求是否可以執(zhí)行跨域操作。

簡單科普下什么是跨域：在A域名網(wǎng)站下，但是里面的js請求卻使用了B域名做資源請求簡稱跨域請求。如果js也是用A域名做資源請求就不會跨域。

問題相關(guān)描述

http基礎(chǔ)知識

請求頭：

Origin : 表示了請求的來源

Referer : 請求頭包含了當(dāng)前請求頁面的來源頁面的地址，即表示當(dāng)前頁面是通過此來源頁面里的鏈接進(jìn)入的。

Access-Control-Request-Method : 請求頭 **Access-Control-Request-Method** 出現(xiàn)于 preflight request（預(yù)檢請求）中，用于通知服務(wù)器在真正的請求中會采用哪種 HTTP 方法。

Access-Control-Request-Headers ： 請求頭 **Access-Control-Request-Headers** 出現(xiàn)于 preflight request（預(yù)檢請求）中，用于通知服務(wù)器在真正的請求中會采用哪些請求頭。

響應(yīng)頭：

Access-Control-Allow-Origin ： **Access-Control-Allow-Origin** 響應(yīng)標(biāo)頭指定了該響應(yīng)的資源是否被允許與給定的來源（origin）共享。（對應(yīng)Origin，說明運(yùn)行在哪個網(wǎng)頁下執(zhí)行跨域請求）

Access-Control-Allow-Methods ：響應(yīng)首部 **Access-Control-Allow-Methods** 在對 preflight request.（預(yù)檢請求）的應(yīng)答中明確了客戶端所要訪問的資源允許使用的方法或方法列表。（支持哪些跨域的http方法）

Access-Control-Allow-Headers ： 響應(yīng)首部 **Access-Control-Allow-Headers** 用于 preflight request（預(yù)檢請求）中，列出了將會在正式請求的 Access-Control-Request-Headers 字段中出現(xiàn)的首部信息。

Access-Control-Allow-Credentials ：**Access-Control-Allow-Credentials** 響應(yīng)頭用于在請求要求包含 credentials（Request.credentials 的值為 include）時，告知瀏覽器是否可以將對請求的響應(yīng)暴露給前端 JavaScript 代碼。（允許跨域行為會返回true）

備注：協(xié)議定義學(xué)習(xí)

跨域訪問過程

1. 在A網(wǎng)頁下面，用了B域名進(jìn)行Get的資源請求（命名為B1），這時候瀏覽器會用B1會自動發(fā)起Options請求（命名為B2），B2會帶上Origin、Refer、Access-Control-Request-Method、Access-Control-Headers等必要請求頭訪問服務(wù)端，服務(wù)端允許該B2請求在A網(wǎng)頁下面進(jìn)行跨域操作，就會在響應(yīng)頭里面插入access_control_allow_origin 、access_control_methods、access_control_allow_headers、 access_control_allow_credentials : true(運(yùn)行進(jìn)行跨域操作)
2. 獲取到響應(yīng)頭4個核心的key和value后，瀏覽器才會用B1進(jìn)行發(fā)起真實(shí)的業(yè)務(wù)請求，這時候B1往頭部access_control_request_headers里面聲明過的key才允許塞入口頭部進(jìn)行請求，最終B1的響應(yīng)頭也會包含access_control_allow_origin 、access_control_methods、access_control_allow_headers、 access_control_allow_credentials這最重要的4個頭部信息，如果缺少一個網(wǎng)絡(luò)層都認(rèn)為不安全，都不會正確返回業(yè)務(wù)數(shù)據(jù)。

解決辦法

本身跨域問題都是需要經(jīng)過服務(wù)端去審核此次行為是否安全，所以不該是客戶端解決。所以應(yīng)該由長連接的服務(wù)端把Options的請求轉(zhuǎn)發(fā)到具體業(yè)務(wù)去校驗其安全性，不應(yīng)該簡單的把Options請求返回200就結(jié)束了。

排查問題思路

1. 對比成功/失敗兩個請求頭和響應(yīng)頭的差距，把字節(jié)流內(nèi)容打印出來。
2. 嘗試代碼寫死缺少的請求頭和響應(yīng)頭，復(fù)現(xiàn)相同場景下是否可以解決該問題。