Http协议请求报文组成
HTTP请求报文由3部分组成（请求行+请求头+请求体）：
下面是一个实际的请求报文：
请求头字段解析
以这个报文为例：
POST /app/game/game_list/ HTTP/1.1
Content-Length: 10
Content-Type: application/x-www-form-urlencoded
Host: zhushou.72g.com
Connection: Keep-Alive
Accept-Encoding: gzip
platform=2
1.Post：代表请求写协议，一般是get或post，区别：
- GET使用URL或Cookie传参。而POST将数据放在BODY中。
- GET的URL会有长度上的限制，则POST的数据则可以非常大。
- POST比GET安全，因为数据在地址栏上不可见。
/app/game/game_list/ HTTP/1.1：/app/game/game_list/ 是url中除服务器地址外的path，HTTP/1.1：使用的http协议版本
- Content-Length：body中内容的长度
3.Content-Type：body中内容的类型，默认为application/x-www-form-urlencoded，使用url编码的表单数据类型，还可以指定内容的编码：Content-Type: application/x-www-form-urlencoded;charset=utf-8
其他常见类型：
- multipart/form-data
这又是一个常见的 POST 数据提交的方式。我们使用表单上传文件时，必须让 form 的 enctyped 等于这个值。直接来看一个请求示例（一个请求发送了两段不一样的数据，一个是文本，一个是png图片）：
POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryrGKCBY7qhFd3TrwA
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="text"
title
------WebKitFormBoundaryrGKCBY7qhFd3TrwA
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png
PNG ... content of chrome.png ...
------WebKitFormBoundaryrGKCBY7qhFd3TrwA--
这个例子稍微复杂点。首先生成了一个 boundary 用于分割不同的字段，为了避免与正文内容重复，boundary 很长很复杂。然后 Content-Type 里指明了数据是以 mutipart/form-data 来编码，本次请求的 boundary 是什么内容。消息主体里按照字段个数又分为多个结构类似的部分，每部分都是以 --boundary 开始，紧接着内容描述信息，然后是回车，最后是字段具体内容（文本或二进制）。如果传输的是文件，还要包含文件名和文件类型信息。消息主体最后以 --boundary-- 标示结束。
这种方式一般用来上传文件，各大服务端语言对它也有着良好的支持。
上面提到的这两种 POST 数据的方式，都是浏览器原生支持的，而且现阶段原生 form 表单也只支持这两种方式。
- application/json
application/json 这个 Content-Type 作为响应头大家肯定不陌生。实际上，现在越来越多的人把它作为请求头，用来告诉服务端消息主体是序列化后的 JSON 字符串。
可以使用这种方式直接提交json请求，也可以把 JSON 字符串作为 val，仍然放在键值对里，以 x-www-form-urlencoded 方式提交
以下报文直接提交了json请求：
POST http://www.example.com HTTP/1.1
Content-Type: application/json;charset=utf-8
{"title":"test","sub":[1,2,3]}
- text/xml：
POST http://www.example.com HTTP/1.1
Content-Type: text/xml
<!--?xml version="1.0"?-->
<methodcall>
<methodname>examples.getStateName</methodname>
<params>
<param>
<value><i4>41</i4></value>
</params>
</methodcall>
- Host: zhushou.72g.com：服务器地址
- Connection: Keep-Alive :客户端和服务器保持长时间链接
- Accept-Encoding: gzip：接收的响应数据，编码格式应该为gzip
HTTP的响应报文结构
HTTP的响应报文也由三部分组成（响应行+响应头+响应体）
以下是一个实际的HTTP响应报文：
①报文协议及版本；
②状态码及状态描述；
③响应报文头，也是由多个属性组成；
④响应报文体，即我们真正要的“干货”。
响应报文字段解析：
- 响应状态码
HTTP的响应状态码由5段组成：
- 1xx 消息，一般是告诉客户端，请求已经收到了，正在处理，别急...
- 2xx 处理成功，一般表示：请求收悉、我明白你要的、请求已受理、已经处理完成等信息.
- 3xx 重定向到其它地方。它让客户端再发起一个请求以完成整个处理。
- 4xx 处理发生错误，责任在客户端，如客户端的请求一个不存在的资源，客户端未被授权，禁止访问等。
- 5xx 处理发生错误，责任在服务端，如服务端抛出异常，路由出错，HTTP版本不支持等
- Content-Type:响应报文的类型
- Content-Encoding：响应报文的编码
网友评论