Android 网络全栈攻略（五）—— 从 OkHttp 拦截器来看 HTTP 协议二
上一篇我们介绍了 OkHttp 的责任链以及第一个内置拦截器 —— 重试与重定向拦截器。本篇我们将剩余四个拦截器的解析做完。
1、桥接拦截器
BridgeInterceptor 作为请求准备和实际发送之间的桥梁，自动处理 HTTP 请求头等繁琐工作。比如设置请求内容长度，编码，gzip 压缩，Cookie 等，获取响应后保存 Cookie 等。它的设计目的是为了解决开发者手动处理 HTTP 协议细节的麻烦，特别是那些必须做但很繁琐或难以实现的工作。
它的拦截代码 intercept() 如下：
class BridgeInterceptor(private val cookieJar: CookieJar) : Interceptor {@Throws(IOException::class)override fun intercept(chain: Interceptor.Chain): Response {// 1.前置工作：从责任链上获取请求，添加相关请求头val userRequest = chain.request()val requestBuilder = userRequest.newBuilder()val body = userRequest.bodyif (body != null) {val contentType = body.contentType()if (contentType != null) {requestBuilder.header("Content-Type", contentType.toString())}// 请求体内容长度如果不是 -1 意味着使用 Content-Length 这个请求头展示内容大小，// 否则就是要使用 Transfer-Encoding: chunked 分块传输的方式。这两个头互斥val contentLength = body.contentLength()if (contentLength != -1L) {requestBuilder.header("Content-Length", contentLength.toString())requestBuilder.removeHeader("Transfer-Encoding")} else {requestBuilder.header("Transfer-Encoding", "chunked")requestBuilder.removeHeader("Content-Length")}}if (userRequest.header("Host") == null) {requestBuilder.header("Host", userRequest.url.toHostHeader())}// Connection 头自动开启了长连接if (userRequest.header("Connection") == null) {requestBuilder.header("Connection", "Keep-Alive")}// 在没有 Accept-Encoding 与 Range 这两个请求头的情况下，自动添加 gzip 压缩数据var transparentGzip = falseif (userRequest.header("Accept-Encoding") == null && userRequest.header("Range") == null) {transparentGzip = truerequestBuilder.header("Accept-Encoding", "gzip")}val cookies = cookieJar.loadForRequest(userRequest.url)if (cookies.isNotEmpty()) {requestBuilder.header("Cookie", cookieHeader(cookies))}if (userRequest.header("User-Agent") == null) {requestBuilder.header("User-Agent", userAgent)}// 2.中置工作：启动责任链的下一个节点，做接力棒交接val networkResponse = chain.proceed(requestBuilder.build())// 3.后置工作：修改响应cookieJar.receiveHeaders(userRequest.url, networkResponse.headers)val responseBuilder = networkResponse.newBuilder().request(userRequest)// 如果在第 1 步中使用了 gzip 压缩，那么这里在拿到响应 networkResponse 后，需要将响应体// responseBody 解压后放到新的响应体 responseBuilder.body() 中if (transparentGzip &&"gzip".equals(networkResponse.header("Content-Encoding"), ignoreCase = true) &&networkResponse.promisesBody()) {val responseBody = networkResponse.bodyif (responseBody != null) {val gzipSource = GzipSource(responseBody.source())val strippedHeaders = networkResponse.headers.newBuilder().removeAll("Content-Encoding").removeAll("Content-Length").build()responseBuilder.headers(strippedHeaders)val contentType = networkResponse.header("Content-Type")responseBuilder.body(RealResponseBody(contentType, -1L, gzipSource.buffer()))}}return responseBuilder.build()}
}
桥接拦截器的拦截逻辑还是很清晰的，三步走：
- 前置工作为请求添加请求头。当请求体长度 contentLength 不为 -1 时，添加 Content-Length 请求头填入请求体的完整长度；否则意味着要使用分块传输，添加
Transfer-Encoding: chunked请求头。这两个头互斥，只能存在一个 - 中置工作启动下一个责任链节点，进而触发缓存拦截器
- 后置工作就一项，如果在前置工作中启动了 gzip 数据压缩，那么在拿到响应后，要把响应体解压放到新的响应中