[DESCRIPTION]
下载GZIP压缩的文件时，暂停后点击续传，提示续传失败。
[SOLUTION]
首先需要通过Log确定当前下载的多媒体文件是否以Gzip压缩传输。具体可以参考FAQ ID: FAQ02216 [Download]为
什么下载时不能显示文件大小，且进度条和百分比数字无法更新 和 ID: FAQ00547 [OBIGO]如何从catcher log中提取
出网页源代码 ，了解GZIP字段的影响和提取网络数据包查看Gzip字段的方法。
当多媒体文件以Gzip方式传输时，手机端是不考虑Content-Length的取值的，而是一边保存数据边记录大小。如下
是一个例子：
从Log提取出的数据，可以看到此时server返回给我们的数据是：
HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Length: 5900
Date: Tue, 30 Oct 2012 08:41:17 GMT
Content-Encoding: gzip
……
我们可以看到，server对数据进行了Gzip压缩，此时， Content-Length:5900就不是实际的多媒体文件大小。手机端
将其忽略，并一边下载一边记录大小。假设在手机端保存到了6065B 时点击暂停，再点击续传，交互的数据如下：
GET ……
Range: bytes=6065-
Accept-Encoding: gzip, deflate, base64, quoted-printable
……
HTTP/1.1 416 Requested Range Not Satisfiable
Content-Length: 314
……

Requested Range Not Satisfiable

None of the range-specifier values in the Range
request-header field overlap the current extent
of the selected resource.

我们可以看到，在发送续传请求时，我们将已下载的Size 6065 发送给server。但是这个Size已经大于之前
server给我们提供的Content-Length的长度，因此，server向手机端返回了416 Requested Range Not Satisfiable错
误。手机端提示用户续传失败。
针对上面的这种数据case，手机端是没有办法，只能处理416错误，然后提示失败。
我们可以从如下两个思路处理这个问题：
1 ，将HTTP request header中，Accept-Encoding:字段中的Gzip去掉，即不告知server手机端支持Gzip压缩编码
。这样，server给我们的数据有可能就会是明文的方式，而不会有此问题。但是这一修改会影响到普通的上网。
2 ，保留Accept-Encoding:字段中Gzip编码。在点击续传时，如果检测到之前是采用了Gzip压缩，那不对server发
送 Range: bytes=6065-字段。这样，就相当于重新在开云棋牌官网在线客服社区下载了。可以参考如下思路实现：
2.1 在函数 mmi_da_recv_wap_file_dl_ind()和mmi_da_oma_http_response_callback()中，找到对对 “ ETag”标
签解析的地方，可以参考这里，对header中的Content-Encoding: gzip进行解析。如果存在的话，设置一个标志位。
2.2 在函数mmi_da_util_gen_http_header_to_resume()和mmi_da_wps_send_http_req()中，找到添加Range字段添
加的地方。在这里增加一个判断，如果前面的Gzip标志位为TRUE，则不添加Range字段，或者令Range字段的值为0。