ABNF范式：https://www.jianshu.com/p/fe82f22f09f6
回顾下ABNF范式对HTTP包体的描述
message-body = *OCTET
OCTET为8位数据
*OCTET为二进制流
HTTP是应用层协议，除了发送数据后，还得告诉上层应用这是什么数据（头部定义）
如何告诉是什么数据，参考了MIME规范
有时候为了节约带宽，在传输过程中还会压缩数据，所以还需要一个Encoding type告诉对方用了什么编码
content := " Content-Type " ":" type "/" subtype *(";" parameter)
type := discrete-type / composite-type discrete-type :="text" / "image" / "audio" / "video" / "application" / extention-tokencomposite-type := "message" / "multipart" / extension-token extension-token :=ietf-token / x-tokensubtype :=extension-token / iana-tokenparameter := attribute "=" value
客户端用 Accept 头告诉服务器希望接收什么样的数据，而服务器用 Content 头告诉客户端实际发送了什么样的数据
请求发送方
响应
Accept-Encoding字段标记的是客户端支持的压缩格式，例如上面说的 gzip、deflate 等，同样也可以用“,”列出多个，服务器可以选择其中一种来压缩数据，实际使用的压缩格式放在响应头字段Content-Encoding里
浏览器能接受的压缩方式
响应数据时使用的压缩方式
同理语言：Accept-Language和Content-Language
编码：Accept-Charset和Content-Charset
请求发送方
我们将这些双方对消息包体的内容约束称为内容协商（还有质量因子q）
HTTP包体的传输方式
包体的传输方式分为两种
1.定长传输
这个很常见，即在发送HTTP消息时已经能够确定包体的长度
其中包体的长度我们在头部Content-Length中指明
Content-Length = 1*DIGIT
DIGIT为10进制
为什么要用10进制表示，因为这需要被我们肉眼所观察到
那么如果两者不一致会出现什么情况？即Content-length和包体实际长度不一致
我们实验测试一下
这里我用php的swoole搭建（需要安装最新swoole扩展）
搭建简单的socket服务器
再来回顾下ABNF对响应的定义
HTTP-message = status-line *(header-field CRLF)CRLF [message-body]
其中CRLF就相当于 \r\n
先改成与实际长度相同
运行程序，分别浏览器访问和curl观察结果
浏览器返回
curl结果
当Content-length<实际长度
只显示5个字节
curl结果当Content-length>实际长度
浏览器无响应
curl无响应
2.不定长传输
后面不太理解，先记录别人的笔记
使用Transfer-Encoding头部指明使用的Chunk传输方式
含Transfer-Encoding头部后Content-Length头部应被忽略
优点：
基于长连接持续推送动态内容
压缩体积较大的包体时，不必完全压缩完（计算出头部）再发送，可以边发送边压缩
传递必须在包体传输完才能计算出的 Trailer 头部
表单提交时的包体格式
1.在表单提交时我们通常采用POST方法提交
2.在上传文件的表单中，我们通常会对表单的enctype添加选项
application/x-www.form-urlencode
抛出问题：为什么通常会进行以上约定？
关于enctype
enctype属性是在POST方法下对表单内容在请求包体中的提交方式
在w3c中有以下定义
w3c规范
默认地，表单数据会编码为 "application/x-www-form-urlencoded"
1.代码抓包测试
1.1.post和get的区别
post和get区别
GET提交：
在wireshark中表单数据以路由参数(明文)的形式显示
1.1GET抓包
并且是在请求头中
POST：
在谷歌浏览器抓包面板中以包体明文的方式传输(点击view source展开)
1.1POST
wireshark抓包
两者以&编码连接
总结：
在POST提交中，采用了application/x-www-form-urlencoded编码方式传输
并且该编码将参数以 & 方式连接
1.2.multipart/form-data的编码方式？
text/plain仅将空格转为+
代码环境
先不上传文件对比
wireshark抓包content-type显示
在Content-type中多了一堆看不懂的玩意儿
RFC中对Content-type为multipart/form-data时的描述
multipart直译为多部份
multipart/form-data即为一个包体中多个资源的表述
即表单中的每一个输入框都为独立的资源描述
RFC描述：
Contetn-Type: multipart/form-data;Boundray
其中Boundray为
boundray := 0*69<bchars> bcharsnospace;
·bchars := bcharsnospace / " "
·bcharsnospace := DIGIT / ALPHA / "" / "(" / ")" / "+" / "-" / "." / "/" /"=" / "?"
boundray不超过70个字符即
boundray不超过70个字符
RFC对multipart包体格式的描述
其中第一个部分(preamble)和最后一个部分(epilogue)一般不使用，使用的时候接收端也会丢弃掉，所以不关注
1*encapsulation表示表单中每一个输入框都为一个encapsulation
wireshark显示4个encapsulation
最后结尾以close-delimiter即再加--
网友评论