一次content-length的教训
有一次使用springMVC写的接口,在调用的时候传了content-lengt,在传单个数字的时候可以调通,其他参数时死活就是不通。最后经过查资料发现是content-lengt计算错误。
对于http的请求返回结果要进行内容的长度校验主要有两种方式,二者互斥使用
1.客户端在http头(head)加Connection:keep-alive时,服务器的response是Transfer-Encoding:chunked的形式,通知页面数据是否接收完毕,例如长连接或者程序运行中可以动态的输出内容,例如一些运算比较复杂且需要用户及时的得到最新结果,那就采用chunked编码将内容分块输出。
2.除了如1所述之外的情况一般都是可以获取到Content-Length的。
在HTTP协议中,Content-Length用于描述HTTP消息实体的传输长度the transfer-length of the message-body。在HTTP协议中,消息实体长度和消息实体的传输长度是有区别,比如说gzip压缩下,消息实体长度是压缩前的长度,消息实体的传输长度是gzip压缩后的长度。
在具体的HTTP交互中,客户端是如何获取消息长度的呢,主要基于以下几个规则:
- 响应为1xx,204,304相应或者head请求,则直接忽视掉消息实体内容。
- 如果有Transfer-Encoding,则优先采用Transfer-Encoding里面的方法来找到对应的长度。比如说Chunked模式。
- “如果head中有Content-Length,那么这个Content-Length既表示实体长度,又表示传输长度。如果实体长度和传输长度不相等(比如说设置了Transfer-Encoding),那么则不能设置Content-Length。如果设置了Transfer-Encoding,那么Content-Length将被忽视”。这句话翻译的优点饶,其实关键就一点:有了Transfer-Encoding,则不能有Content-Length。
- Range传输。不关注,没详细看了:)
- 通过服务器关闭连接能确定消息的传输长度。(请求端不能通过关闭连接来指明请求消息体的结束,因为这样可以让服务器没有机会继续给予响应)。这种情况主要对应为短连接,即非keep-alive模式。
- HTTP1.1必须支持chunk模式。因为当不确定消息长度的时候,可以通过chunk机制来处理这种情况。
- 在包含消息内容的header中,如果有content-length字段,那么该字段对应的值必须完全和消息主题里面的长度匹配。
“The entity-length of a message is the length of the message-body before any transfer-codings have been applied”
也就是有chunk就不能有content-length 。
其实后面几条几乎可以忽视,简单总结后如下:
1、Content-Length如果存在并且有效的话,则必须和消息内容的传输长度完全一致。(经过测试,如果过短则会截断,过长则会导致超时。)
2、如果存在Transfer-Encoding(重点是chunked),则在header中不能有Content-Length,有也会被忽视。
3、如果采用短连接,则直接可以通过服务器关闭连接来确定消息的传输长度。(这个很容易懂)
结合HTTP协议其他的特点,比如说Http1.1之前的不支持keep alive。那么可以得出以下结论:
1、在Http 1.0及之前版本中,content-length字段可有可无。
2、在http1.1及之后版本。如果是keep alive,则content-length和chunk必然是二选一。若是非keep alive,则和http1.0一样。content-length可有可无
我总结我的例子 如果 要是 js css html 这样的文件的话 会返回 contengt-length 字节 前提是 nginx 里的gzip off 如果是on 的话 返回 chunk
执行的如果是 动态 脚本的话, 还是返回chunk 前提是 content:keep-alive 如果不是长连接的话 返回的头里面没有content-leght ()
一次content-length的教训相关推荐
- The maximum string content length quota (8192) has been exceeded while reading XML data
原文: The maximum string content length quota (8192) has been exceeded while reading XML data 问题场景:在我们 ...
- Posted content length of 26789546 exceeds limit of 10485760
原来jfinal中默认上传为10M(10*1024*1024),故超过10M会报错 注:https://blog.csdn.net/weixin_43706875/article/details/10 ...
- MAC | svn: E175002: DAV request failed: 411 Content length required.
今天在做svn compare的时候发现的这个问题 ! 网上有人说: 这可能是因为您的后端是较旧的svn版本. 在.subversion / servers文件中添加如下代码 [global] htt ...
- FastCGI - Getting Request URI and Content in C++ FCGI
注:该博文转自 Getting Request URI and Content in C++ FCGI,由于网上FastCGI相关的资料较少,故转载存档.原文章创作于2012年,原文中部分链接资料已经 ...
- ui设计师常用的设计工具_2020年应该使用哪个UI设计工具?
ui设计师常用的设计工具 重点 (Top highlight) It's 2020, the market today is saturated with UI design tools. Ever ...
- 高并发 高负载 网站系统架构
高并发 高负载 网站系统架构 注:我看到这篇文章写的太好了,可以没法转到CSDN上我就COPY了,看到下面激烈的评论,我也一并COPY了.不过还是要谢谢哪位作者了.这样的文章很少. 转自:http:/ ...
- 高并发高负载网站系统架构
我在CERNET做过拨号接入平台的搭建,而后在Yahoo&3721从事过搜索引擎前端开发,又在MOP处理过大型社区猫扑大杂烩的架构升级等工作,同时自己接触和开发过不少大中型网站的模块,因此在大 ...
- 大型高并发高负载网站的系统架构
转载请保留出处:俊麟 Michael's blog (http://www.toplee.com/blog/?p=71) Trackback Url : http://www.toplee.com/b ...
- 编写大并发高负载通讯程序
更是涉及面非常广,从硬件到软件.编程语言.数据库.WebServer.防火墙等各个领域都有了很高的要求,已经不是原来简单的html静态网站所能比拟的. 大型网站,比如门户网站.在面对大量用户访问.高并 ...
- 大学Java基础课程设计——网络聊天室
不登高山,不知天之高也:不临深溪,不知地之厚也. | @Author:TTODS 目录 项目简介 系统设计与实现 聊天室系统的总体设计 服务器端功能设计 客户端功能设计 数据包 用户操作处理流程 客户 ...
最新文章
- LibreOJ #113. 最大异或和
- 读文件 —— 读写配置文件
- 构建轻量级的Table View注意事项[UIKit]
- 高效Java编程工具集锦
- 5.1 jQuery基础
- Powershell-创建Module
- Create Volume 操作(Part I) - 每天5分钟玩转 OpenStack(50)
- 一、Arcgis api js -- 基本概念
- D3 treecluster
- java体系的中间件适用于go吗_golang gf框架自定义中间件实现管理界面授权
- 停滞数年后,ElasticJob 携首个 Apache 版本 3.0.0-alpha 回归!
- MySQL数据库页损坏怎么办,innodb_force_recovery参数帮你解决问题
- 韩语在线翻译图片识别_3个OCR文字识别工具,最后一个许多人都不知道!
- 【操作系统】进程通信
- 极客大学python训练营目录_极客大学算法训练营笔记
- React常见面试题及答案
- yolo3各部分代码(超详细)
- ps-色彩模式与图像色彩调整
- ActionBarTest、FragmentTest
- python地铁查询系统_基于Python的苏州实时公交/地铁接口调用代码实例