安装包下载劫持
简述
最近在做项目的时候测试人员反馈了这么一个问题，在线上环境点击页面下载位置，下载后却发现是其他产品。很明显我们的产品广告被运营商盯上了，下载被劫持了…
初步猜想的原因是报文被劫持了！
download
先复习下”下载“的概念～
[download] 属性规定被下载的超链接目标。
解决思路
读完上面的解释后，对于解决这个“偷梁换柱”的问题有什么帮助呢？我们可以在下载链接地址里把APK包的扩展名改成jpg或者其他，让”想要劫持它的坏蛋”看到的是一张图片而不是一个下载包在视觉上混淆，之后在下载请求到CDN后给用户返回APK数据（在header里指定content-type和content-disposition类型为APK，扩展名为APK）,用这种方式来绕开运营商的劫持。这里只是提供一种解决思路，相关修改制药安全工程师分分钟就能解决，重点是我们还需要了解一些细节知识 – 请求报文和响应报文等，这些信息可以在浏览器中的开发者模式下看到。
报文相关知识
报文就是简单的格式化数据块，可以看作是包裹着数据的盒子。每一条报文都包含一条客户端的请求，或者是服务器的响应。
报文的工作流程也叫报文流动
文字示例： 客户端 -> 代理 -> 【服务器】-> 代理 -> 客户端
这里木有华丽的图片展示我们就用文字代替，从箭头指向可以看得出报文一路向下流动～不管是请求报文还是响应报文都会向下流动。
一个HTTP报文请求由请求行（起始行）、请求头（首部）、请求数据3个部分。下面是我截取一张图片的请求信息：
常见的HTTP请求报文
常见HTTP请求报文头属性如下：
Accept: 请求报文可通过一个“Accept”报文头属性告诉服务端、客户端接受什么类型的响应。
Cookie: 客户端的Cookie就是通过这个报文头属性传给服务端的哦!
Referer: 表示这个请求是从哪个URL过来的，假如你通过google搜索出一个商家的广告页面，你对这个广告页面感兴趣，鼠标一点发送一个请求报文到商家的网站，这个请求报文的Referer报文头属性值就是http://www.google.com。
Cache-Control: 对缓存进行控制，相当于让服务端将对应请求返回的响应内容不要在客户端缓存
常见的HTTP响应报文
常见的几种响应状态码：
200 OK: 最希望看到的反馈，即处理成功！
303 See Other: 被重新定向到到其它的页面，目标的URL通过响应报文头告诉它的位置。
304 Not Modified: 告诉客户端，请求的这个资源至上次取得后并没有更改，可以直接用本地的缓存好的!
404 Not Found: 最不希望看到的，即找不到页面。如在baidu上找到一个页面，点击这个链接返回404，表示这个页面已经被网站删除了。
500 Internal Server Error: 看到这个错误，就表示需要查看下服务端的日志了，肯定抛出了异常！
常见的HTTP响应报文头属性
Cache-Control: 响应输出到客户端后，服务端通过该报文头属告诉客户端如何控制响应内容的缓存。
Location: 我们在JSP中让页面重新定向到一个某个A页面中，其实是让客户端再发一个请求到A页面，这个需要定向到的A页面的URL，其实就是通过响应报文头的Location属性告知客户端的。
Set-Cookie: 服务端可以设置客户端的Cookie，其原理就是通过这个响应报文头属性实现的
刚学的新知识，还需继续完善～