目录
- 背景
- 系统库如何设计的
- 解决方案
- 方案一
- 方案二
背景
在源网页通过服务器重定向打开某个三方网页,网络层出现了 -1005 (NSURLErrorNetworkConnectionLost) 错误码,排查差异后发现是由于给这个三方服务带了源网页特有的 HTTP Header,导致服务器检查异常从而断开连接。
核心原因是跨域重定向场景透传了 Header 带到了三方服务,这有些不符合常理,会带来两个明显的问题:
- 敏感 HTTP Header 传递给三方服务,存在隐私安全问题;
- 服务收到未预期的 HTTP Header,可能被视为非法访问,导致网页异常;
系统库如何设计的
NSURLSession 在跨域重定向场景默认会透传 HTTP Header,参考 Swift 在 _HTTPURLProtocol 的相关处理:
/// If the response is a redirect, return the new request /// RFC 7231 section 6.4 defines redirection behavior for HTTP/1.1 /// - SeeAlso: <https://tools.ietf.org/html/rfc7231#section-6.4> func redirectRequest(for response: HTTPURLResponse, fromRequest: URLRequest) -> URLRequest? { //TODO: Do we ever want to redirect for HEAD requests? guard let location = response.value(forHeaderField: .location), let targetURL = URL(string: location) else { // Can't redirect when there's no location to redirect to. return nil } var request = fromRequest // Check for a redirect: switch response.statusCode { case 301...302 where request.httpMethod == "POST", 303: // Change "POST" into "GET" but leave http://www.devze.comother methods unchanged: request.httpMethod = "GET" request.httjspBody = nil case 301...302, 305...308: // Re-use existing method: break default: http://www.devze.com return nil } // If targetURL has only relative path of url, create a new valid url with relative path // Otherwise, return request with targetURL ie.url from location field guard targetURL.scheme == nil || targetURL.host == nil else { request.url = targetURL return request } … (后面是相对路径处理) }
大致处理流程为:
- 取出响应头 Location 字段作为目标 URL;
- 若为 POST 请求改为 GET 请开发者_C培训求并清空其 Body;
- 若目标 URL 为相对路径,补齐完整 URL;
可以看到重定向后的请求会直接继承 HTTP Header,这个处理遵循了 RFC 7231 的规范,大致去翻了一下,只描述了 Location header field 的处理方法,而没有说明其它请求头该如何处理,在 Chrome 下重定向场景应该是直接丢弃之前的 Header 的。
我们知道有一www.devze.com个公开代理方法…willPerformHTTPRedirection…
可以去改变重定向请求,但如果不借助网络拦截技术,WebKit 里面的请求也无法修改,顺便看一下 WebKit 内部是否对这种场景有所处理。
WebKit 是在 NetworkSessionCocoa 类里面承载 NSURLSession 请求的,实现了URLSession:task:willPerformHTTPRedirection:newRequest:completionHandler:
协议,顺着处理链路从 Network 进程跟到 Web 进程再跟到 APP 进程,都没有找到关于跨域重定向清理 HTTP Header 的处理,更不用说公开配置能力了。
解决方案
针对 WebView 需要跨域重定向的场景,如何避免私有 HTTP Header 传递给目标请求服务?
方案一
如果前置请求是为了做统计上报,那可以直接跳转到目标 URL,前置请求旁路去处理;如果前置请求是为了获取跳转的地址,那么可以发起一个 AJAX 请求拿到回包后去跳转目标 URL。
或者更直接的,把 server-side redirectphp 改为 client-side redirect,让前置请求返回文档,文档内部进行document.replace()
等函数跳转到目标 URL,但这种处理会让性能劣化,并且会导致前置请求关联的 Web 进程历史栈缓存被清理
核心思想就是避免服务器跨域重定向,由于和 Chrome 内核表现不一致且前端改造成本较大,一般较难实施,但这对于没有 WebKit 网络拦截技术的 APP 来说可能是唯一思路。
方案二
如果有 WebKit 网络拦截技术,那处理就比较简单了,只需要保证在重定向请求发起之前,如果主域名发生变化,就把 APP 私有的请求头清理掉,较简单的规避系统设计问题。
以上就是NSURLSession跨域重定向透传HTTP Header问题解决的详细内容,更多关于NSURLSession跨域重定向的资料请关注我们其它相关文章!
精彩评论