动脑学院架构篇-HTTP请求、响应报文格式

【HTTP】HTTP请求、响应报文格式

HTTP请求报文格式:

HTTP请求报文主要由请求行、请求头部、请求数据3部分组成

1，请求行

由3部分组成，分别为：请求方法、URL（见备注1）以及协议版本，之间由空格分隔

请求方法包括GET、HEAD、PUT、POST、TRACE、OPTIONS、DELETE以及CONNECT等扩展方法，当然并不是所有的服务器都实现了所有的方法，部分方法即便支持，处于安全性的考虑也是不可用的

协议版本的格式为：HTTP/主版本号.次版本号，常用的有HTTP/1.0和HTTP/1.1

2，请求头部

请求头部为请求报文添加了一些附加信息，由“名/值”对组成，每行一对，名和值之间使用冒号分隔

请求头部的最后会有一个空行，表示请求头部结束，接下来为请求正文，这一行非常重要，必不可少

3，请求数据

可选部分，比如GET请求就没有请求数据

GET请求示例：

get.png

POST请求示例：

post.png

HTTP响应报文格式:

HTTP响应报文主要由状态行、响应头部、响应正文3部分组成

1，状态行

由3部分组成，分别为：协议版本，状态码，状态码描述，之间由空格分隔
状态代码为3位数字，200_{299的状态码表示成功，300}399的状态码指资源重定向，400_{499的状态码指客户端请求出错，500}599的状态码指服务端出错（HTTP/1.1向协议中引入了信息性状态码，范围为100~199）

这里列举几个常见的：

2，响应头部

与请求头部类似，为响应报文添加了一些附加信息

常见响应头部如下：

常见响应头部示图

响应示例：

如上，在解析请求的时候，可能遇见的Transfer-Encoding响应头，而没有Content-Length。

表示编码方式：
Transfer-Encoding: chunked
Transfer-Encoding: compress
Transfer-Encoding: deflate
Transfer-Encoding: gzip
Transfer-Encoding: identity

指令

• chunked
  数据以一系列分块的形式进行发送。 Content-Length 首部在这种情况下不被发送。。在每一个分块的开头需要添加当前分块的长度，以十六进制的形式表示，后面紧跟着 '\r\n' ，之后是分块本身，后面也是'\r\n' 。终止块是一个常规的分块，不同之处在于其长度为0。终止块后面是一个挂载（trailer），由一系列（或者为空）的实体消息首部构成。
• compress
  采用 Lempel-Ziv-Welch (LZW) 压缩算法。这个名称来自UNIX系统的 compress 程序，该程序实现了前述算法。
  与其同名程序已经在大部分UNIX发行版中消失一样，这种内容编码方式已经被大部分浏览器弃用，部分因为专利问题（这项专利在2003年到期）。
• deflate
  采用 zlib 结构 (在 RFC 1950 中规定)，和 deflate 压缩算法(在 RFC 1951 中规定)。
• gzip
  表示采用 Lempel-Ziv coding (LZ77) 压缩算法，以及32位CRC校验的编码方式。这个编码方式最初由 UNIX 平台上的 gzip 程序采用。处于兼容性的考虑， HTTP/1.1 标准提议支持这种编码方式的服务器应该识别作为别名的 x-gzip 指令。
• identity
  用于指代自身（例如：未经过压缩和修改）。除非特别指明，这个标记始终可以被接受。

Android开发交流群 481302961