《HTTP权威指南》读书笔记（三） ：报文

1、什么是报文？

　　HTTP报文是在HTTP应用程序之间发送的数据块。如果是HTTP是因特网的快递员，那么报文就是包裹。

 

2、报文是如何流动的？

　　HTTP使用术语流入和流出来描述事务处理的方向。报文流入源端服务器，工作完成后，会流回到用户的Agent代理中。

　　HTTP会像河水一样，不管是请求报文和响应报文都会向下流动，报文的发送者在上游。

 

　　如上图，在请求中，代理1为代理2的发送者，但对于响应报文来说，代理1则作为代理2的下游。

 

3、报文的组成部分

　　报文由三个部分组成

1. 起始行（start line）：对报文进行描述
2. 首部（header）：包含属性
3. 主体（body）：可选的，包含数据。

　　起始行和首部是由行分隔的ASCII文本，每行以一个由一个回车符(13)+一个换行符(10)组成的行终止序列(CRLF)作为结束。书中提到，一个稳健的应用程序除了接受HTTP规范的CRLF来表示行终止，还应该接受单个换行符作为行终止符。

　　主体可以包含文本数据或者二进制数据，也可以为空。

 

 4、报文的语法

　　请求报文：

<method> <request-URL> <version>
<headers>

<entity-body>

 

　　响应报文(只有起始行语法不同)：

<method> <status> <reason-phrase>
<headers>

<entity-body>

 

　　请求报文示例：

GET https://www.cnblogs.com/u/zoujiejun96 HTTP/2.0
Host: www.cnblogs.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Accept: text/css,*/*;q=0.1
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate, br
Referer: https://www.cnblogs.com/
Cookie: _ga=GA1.2.748727080.1535962671; _gid=GA1.2.696154965.1535962671
Connection: keep-alive

　　响应报文示例：

HTTP/2.0 200 OK
server: Tengine
date: Tue, 04 Sep 2018 17:41:43 GMT
content-type: text/css; charset=utf-8
vary: Accept-Encoding
cache-control: public
expires: Wed, 04 Sep 2019 17:41:43 GMT
last-modified: Tue, 04 Sep 2018 17:41:43 GMT
vary: User-Agent
x-ua-compatible: IE=10
content-encoding: gzip
X-Firefox-Spdy: h2

#body

• • 方法(method): 客户端希望服务器对资源执行的动作。如示例中的 GET
  • 请求URL(request-URL): 所请求的资源，或者URL路径组件中的完整URL。如示例中的：https://cnblogs.com/u/zoujiejun96
  • 版本(version): HTTP版本，格式为 HTTP/大版本号.小版本号，如示例中的HTTP/2.0
  • 状态码(status-code): 描述请求过程中所发生的情况。
  • 原因短语(reason-phrase):数字状态码的可读版本，包含行终止列前的所有文本，如示例中的OK。该短语只对人类有意义，不管是200 OK 或者 200 ERROR 对于应用程序来说都是一样的，同样都会被当作成功指示处理。
  • 首部(header):可以有零个或多个首部，每个首部的格式都为 key: value，然后接一个CRLF。首部是用CRLF结束的。 一组HTTP首部总是应该以一个仅有CRLF的空行结束，但由于历史原因，很多客户端和服务器都在没有实体的时候，省略了最后的CRLF。为了对这些流行但是不规范的报文进行处理，客户端和服务器都应该接受那些没有最后那个CRLF的报文.
  • 实体的主体部分(body):任意数据组成的数据块。

 

5、常用的HTTP方法

　　　　安全方法：HTTP定义了一组被称为安全方法的方法，GET和HEAD都被认为是安全的，安全方法意味着HTTP请求不会再服务器上产生什么结果(实际上由Web服务器开发者决定)，使用安全方法的目的就是当使用可能引发某一动作的不安全方法时，允许HTTP应用程序开发者通知用户。

方法	描述	是否包含主体
GET	从服务器获取一份文档	否
HEAD	只从服务器获取文档的首部	否
POST	向服务器发送需要处理的数据	是
PUT	将请求的主体部分存储在服务器上	是
TRACE	对可能经过代理服务器传送到服务器上去的报文进行追踪	否
OPTIONS	决定可以在服务器上执行哪些方法	否
DELETE	删除一份文档	否

 

 

 

 

 

 

　　并不是所有的服务器都实现了这7种方法，其他服务器可能还会实现一些自己的请求方法，这些附加方法是对HTTP规范的扩展，被称为扩展方法。

　　　　HEAD方法：行为与GET类似，但在服务器响应中只返回header而没有body，允许客户端在未获取实际资源的情况下，对资源的首部进行检查。

• • • 　在不获取资源的情况下了解资源的情况（比如：判断其类型）；
    • 　通过查看响应中的状态码，查看某个对象是否存在；
    •     通过查看header，测试资源是否被修改；

　　　　　　注：服务器开发者必须确保返回的首部与GET请求所返回的首部完全相同。遵循HTTP/1.1规范，就必须实现HEAD方法。

 

　　　　TRACE方法：客户端发起一个请求时，这个请求可能通过防火墙、代理、网关或其他一些应用程序。原始HTTP请求可能发生改变，TRACE方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子。

　　　　　　　　　　　TRACE请求会在服务器端发起一个“环回”诊断，行程最后一站的服务器会弹回一条TRACE响应，并在响应body中携带收到的请求报文，客户端便可以对比响应中的请求报文和原始请求报文。

　　　　　　　　　　　TRACE方法主要用于诊断，验证请求是否如愿穿过了请求/响应链。

　　　　　　　　　　    TRACE请求中不能带有body，TRACE响应的body中包括服务器收到的请求的精确副本。

 

　　　　OPTION方法：请求Web服务器告知其支持的各种功能。

6、状态码

　　方法用来告诉服务器该做什么事情，而状态码则用来告诉客户端，发生了什么事情。

状态码分类

整体范围	已定义范围	分类	备注
100-100	100-101	信息提示	HTTP/1.0中没有定义1xx状态码，不应向HTTP/1.0客户端发送1xx状态码
200-299	200-206	成功
300-399	300-305	重定向
400-499	400-415	客户端错误
500-599	500-505	服务器错误

 

 

 

 

 

 

 

常见状态码

状态码	原因短语	含义