全部产品
云市场

HTTPDNS iOS、android(安卓)平台:HTTPDNS接入过程中需要注意哪些问题?

更新时间:2018-11-08 10:38:23

在集成HTTPDNS服务时,开发者需要了解下述场景的特殊性及可能涉及的定制需求:

  • 务必编写降级代码

    • 降级代码指的是HTTPDNS无法获取期望结果时的处理代码。
    • 如何降级?走传统的DNS解析流程获取域名对应的IP,可以参考httpdns的demo代码。
  • 终端配置代理情况下的处理机制,参考API手册( https://help.aliyun.com/document_detail/30139.html?spm=5176.doc30123.6.139.V7MWzk )关于代理场景下的处理建议,一个方案是降级处理,另一个方案是采用私有头进行双端配合处理。

  • 使用HTTPDNS服务时,由于多数场景下开发者需要替换URL中的域名信息为IP,导致传统网络库把IP信息作为Cookie对应的域名信息进行存储管理,进而造成一定的困扰。建议类似场景的Cookie管理由用户自己定制管理。

  • HTTPS场景、WebView场景、单服务器服务多域名的HTTPS场景下的HTTPDNS解决方案较通用场景下的解决方案更复杂一些,请参考最佳实践文档( https://help.aliyun.com/document_detail/30143.html?spm=5176.doc30140.6.143.dXwMQ2 )。

  • 参考最佳实践进行Webview场景的HTTPDNS实现时( https://help.aliyun.com/document_detail/30145.html?spm=5176.doc30143.6.145.EwT0aL

    • 请留意Android API < 21时系统库函数只能拦截到请求的url参数,其他参数(包括method、header、body等)都没法正常获取。Android API >= 21时,针对POST请求的body内容,WebResourceRequest接口中并没有提供相应的获取方式。
    • 在Webview场景下,当开发者使用HttpURLConnection进行网络请求时,网络库默认的处理机制会内部消化跳转请求( https://developer.android.com/reference/java/net/HttpURLConnection.html ),该默认行为将导致Webview无法感知跳转行为的存在。即当域名A跳转到域名B后,其附带的其他资源请求如”/render/something.css”依然会被Webview定向到”A/render/something.css”而非”B/render/something.css”,从而导致访问异常。可参考的解决方案即配置HttpURLConnection不自动处理跳转请求,并在shouldInterceptRequest中判断请求响应码,如为跳转响应码则退出拦截降级为原生访问模式,参考示例:
  1. HttpURLConnection.setFollowRedirects(false);
  2. ...
  3. public WebResourceResponse shouldInterceptRequest(WebView view, String url) {
  4. ...
  5. int respCode = conn.getResponseCode();
  6. if (respCode >= 300 && respCode < 400) {
  7. // redirect
  8. return null;
  9. } else if (respCode >= 200 && respCode < 300) {
  10. // normal processing
  11. ...
  12. }
  13. }

上述问题的更详细讨论请参考 http://stackoverflow.com/questions/18237451/android-webviewclient-url-redirection-android-url-loading-system

  • 单服务器服务多域名的HTTPS场景下( https://help.aliyun.com/document_detail/30143.html ),iOS使用NSURLProtocol拦截NSURLSession发起的POST请求时,HTTPBody无法正常获取(系统bug)。解决方案有两个:1. 使用NSURLConnection发POST请求。2. 先将HTTPBody放入HTTP Header field中,然后在NSURLProtocol中再取出来。最佳实践给出了方案2的示例代码。

-