怎样判断GZIP压缩后HTTP响应正文的长度？解决办法
日期：2014-05-16 浏览次数：21655 次
怎样判断GZIP压缩后HTTP响应正文的长度？
使用TCPClient来访问网页时遇到了一个麻烦，客户端是用TCPClient连接IIS，自己写的请求头，服务端是IIS7，开启了动态压缩与静态压缩。
测试的页面大致是这样的，就这么一行文本。
<html><body><p>1</p></body></html>
请求头如果不接受GZIP，一切都是好好的，响应头的Content-Length返回36，于是到NetworkStream读取了36个byte，很顺利。
但请求头允许接受GZIP，响应头的Content-Length变成了139，此时如果到NetworkStream读取139,直接阻塞...跟踪的结果大约是在128时就读完了。
我想请教两件事情，
小问题是为什么开启了压缩之后，返回的内容反而变大了，是不是内容太少导致的？
大问题是如果开启了GZIP，Content-Length不正确的情况下，怎样确定读取到什么位置才结束？
------解决方案--------------------
少内容GZIP后可能会变大
TCPClient，返回长度应该有当前文件的长度吧
改用http组件试试
------解决方案--------------------
内容少的用GZIP压缩后会变大
------解决方案--------------------
虽然说http,也是tcp/ip,TCPClient理论上说也行
IIS，是httpServer,用http组件比较好，请求头可以设置成，它所要求的参数
使用TCPClient来访问网页时遇到了一个麻烦，客户端是用TCPClient连接IIS，自己写的请求头，服务端是IIS7，开启了动态压缩与静态压缩。
测试的页面大致是这样的，就这么一行文本。
<html><body><p>1</p></body></html>
请求头如果不接受GZIP，一切都是好好的，响应头的Content-Length返回36，于是到NetworkStream读取了36个byte，很顺利。
但请求头允许接受GZIP，响应头的Content-Length变成了139，此时如果到NetworkStream读取139,直接阻塞...跟踪的结果大约是在128时就读完了。
我想请教两件事情，
小问题是为什么开启了压缩之后，返回的内容反而变大了，是不是内容太少导致的？
大问题是如果开启了GZIP，Content-Length不正确的情况下，怎样确定读取到什么位置才结束？
------解决方案--------------------
少内容GZIP后可能会变大
TCPClient，返回长度应该有当前文件的长度吧
改用http组件试试
------解决方案--------------------
内容少的用GZIP压缩后会变大
------解决方案--------------------
虽然说http,也是tcp/ip,TCPClient理论上说也行
IIS，是httpServer,用http组件比较好，请求头可以设置成，它所要求的参数
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
