问题描述
在某个地区 DNS被污染的前提下，业务侧希望webView也可以通过走cronet长连接（ip直连）+gslb来跳过local dns那一步，但后续实施的时候发现某个webView页面下的某些js请求响应码虽然是200，但是却没有接收到任何数据内容，前端页面提示接口请求异常。
双端差异
上面都是走cronet和长连接的访问，为啥ios没问题而android有问题呢？和同事重现下路径发现，ios那边是在web.xx.com下面用sapi.xx.com去发起接口请求，是没有Options方法发起的，但是android的webView下的web.xx.com页面下的每个sapi.xx.com每次Get/Post请求都会发起Options请求，和业务服务求助该sapi.xx.com资源请求是否可以执行跨域操作。
简单科普下什么是跨域：在A域名网站下，但是里面的js请求却使用了B域名做资源请求简称跨域请求。如果js也是用A域名做资源请求就不会跨域。
问题相关描述
http基础知识
请求头：
Origin : 表示了请求的来源
Referer : 请求头包含了当前请求页面的来源页面的地址，即表示当前页面是通过此来源页面里的链接进入的。
Access-Control-Request-Method : 请求头 **Access-Control-Request-Method** 出现于 preflight request（预检请求）中，用于通知服务器在真正的请求中会采用哪种 HTTP 方法。
Access-Control-Request-Headers ： 请求头 **Access-Control-Request-Headers** 出现于 preflight request（预检请求）中，用于通知服务器在真正的请求中会采用哪些请求头。
响应头：
Access-Control-Allow-Origin ： **Access-Control-Allow-Origin** 响应标头指定了该响应的资源是否被允许与给定的来源（origin）共享。（对应Origin，说明运行在哪个网页下执行跨域请求）
Access-Control-Allow-Methods ：响应首部 **Access-Control-Allow-Methods** 在对 preflight request.（预检请求）的应答中明确了客户端所要访问的资源允许使用的方法或方法列表。（支持哪些跨域的http方法）
Access-Control-Allow-Headers ： 响应首部 **Access-Control-Allow-Headers** 用于 preflight request（预检请求）中，列出了将会在正式请求的 Access-Control-Request-Headers 字段中出现的首部信息。
Access-Control-Allow-Credentials ：**Access-Control-Allow-Credentials** 响应头用于在请求要求包含 credentials（Request.credentials 的值为 include）时，告知浏览器是否可以将对请求的响应暴露给前端 JavaScript 代码。（允许跨域行为会返回true）
备注：协议定义学习
跨域访问过程
- 在A网页下面，用了B域名进行Get的资源请求（命名为B1），这时候浏览器会用B1会自动发起Options请求（命名为B2），B2会带上Origin、Refer、Access-Control-Request-Method、Access-Control-Headers等必要请求头访问服务端，服务端允许该B2请求在A网页下面进行跨域操作，就会在响应头里面插入access_control_allow_origin 、access_control_methods、access_control_allow_headers、 access_control_allow_credentials : true(运行进行跨域操作)
- 获取到响应头4个核心的key和value后，浏览器才会用B1进行发起真实的业务请求，这时候B1往头部access_control_request_headers里面声明过的key才允许塞入口头部进行请求，最终B1的响应头也会包含access_control_allow_origin 、access_control_methods、access_control_allow_headers、 access_control_allow_credentials这最重要的4个头部信息，如果缺少一个网络层都认为不安全，都不会正确返回业务数据。
解决办法
本身跨域问题都是需要经过服务端去审核此次行为是否安全，所以不该是客户端解决。所以应该由长连接的服务端把Options的请求转发到具体业务去校验其安全性，不应该简单的把Options请求返回200就结束了。
排查问题思路
- 对比成功/失败两个请求头和响应头的差距，把字节流内容打印出来。
- 尝试代码写死缺少的请求头和响应头，复现相同场景下是否可以解决该问题。
