报文流

报文的组成部分

报文语法

1.起始行

2.首部

通用首部，既可以出现在请求报文中也可以出现在响应报文中。

请求首部，提供更多有关请求的信息。

响应首部，提供更多有关响应的信息。

实体首部，描述主题的长度和内容，或者资源本身。

首部延续行

Accept首部

条件请求首部

安全请求首部

代理请求首部

实体缓存首部

内容首部

信息性首部

安全响应首部

3.实体

方法

状态码

3.1 100 ~ 199 信息性状态码

3.2 200 ~ 299 成功状态码

3.3 300 ~ 399 重定向状态码

3.4 400 ~ 499 客户端错误状态码

3.5 500 ~ 599 服务器错误状态码

报文流

TTP报文就是在HTTP应用程序之间发送的数据块，这些数据块采用文本形式，以“元信息（meta-information）” 开头，元信息用于描述报文的内容及含义。

将HTTP报文比喻成像河水一样流动，报文只能流向下游，不能流向上游。

术语 “流入（inbound）”、“流出（outbound）”、“上游（upstream）”、“下游（downstream）” 用来描述报文的传输方向。

报文的组成部分

HTTP报文是简单的格式化数据块，由三部分组成：起始行（start line），首部（header），包含数据的主体（body）

起始行（描述报文）
首部块（属性）
主体部分（主体）

报文语法

所有的HTTP报文都可以分为两类：请求报文（request message）和响应报文（response message）。

起始行不同：请求行由HTTP方法、URL、HTTP版本组成,响应行由HTTP版本、响应状态码、原因短句组成
首部组成不同：包括通用首部、请求首部、响应首部、扩展首部等
主体不同：主体是HTTP报文的负荷，即HTTP要传输的内容。主体可以为空，也可以承载多种类型的数字数据包括图片、视频、HTML、文档、应用程序等

这是请求报文的格式

<method> <request-url> <version>
<headers>

<entity-body>

这是响应报文的格式：

<version> <status> <reason-phrase>
<headers>

<entity-body>

method，客户端希望服务器对资源执行的动作。
request-url，命名所请求资源，或者URL路径组件的完整URL。
version，报文所使用的HTTP版本，格式为：HTTP/<major>.<minor>。
status-code，使用三位数字描述请求过程中发生的情况。
reason-phrase，数字状态码的可读版本。
header，可以有零个或者多个首部，格式为：<key>:[space]<value>[,<value>...]CRLF，整个首部是由一个CRLF结束的。
entity-body，包含由任意数据组成的数据块，有时仅仅是一个CRLF结束符。

1.起始行

所有的HTTP报文都以一个起始行作为开始。

请求报文的起始行说明了要做些什么，

响应报文的起始行则说明发生了什么。

请求行，请求服务器对资源进行一些操作，包含了一个方法、一个请求URL和HTTP的版本，在HTTP/1.0之前，并不要求请求行中包含版本号。
响应行，响应行包含了响应报文使用的HTTP版本、数字状态码以及描述操作状态的原因短语。

2.首部

HTTP首部字段向请求和响应报文中添加了一些附加信息，本质上说，它们只是一些key:value的列表。

通用首部，既可以出现在请求报文中也可以出现在响应报文中。

既可以出现在请求报文头中，也可以出现在响应报文头中；主要是供 “发送端” 向 “接收端” 提供本端信息（不论“发送端”是客户端还是服务器，都通用）

Date: Tue, 3 Oct 1974 02:16:00 GMT		# 用于说明报文创建的时间
Connection: keep-alive					# 用于客户端与服务器之间指定与连接有关的选项
MIME-Version:							# 指示发送端所使用的MIME版本
Transfer-Encoding:						# 告知接收端为了保证报文的可靠传输，本端对报文采用的编码方式

connection，允许客户端和服务器指定与连接有关的选项。
date，报文的创建时间。
mime-version，mime类型的版本。
trailer，分块传输编码。
transfer-encoding，编码方式。
update，发送端想升级版本或者协议。
via，报文经由的节点。
cache-control，缓存指示。

请求首部，提供更多有关请求的信息。

提供更多有关请求的信息，用于客户端向服务器传递一些额外信息，用于客户端向服务器说明是谁在发送请求、请求源于何处，以及客户端希望获得什么样的响应、客户端处理响应的能力（客户端的喜好及能力）。

Accept: */*				# 指示客户端希望收到什么类型的数据
Accept-Charset:			# 告知服务器能够发送哪些 字符集
Accept-Encoding:		# 告知服务器能够发送哪些 编码方式
Accept-Language:		# 告知服务器能够发送哪些 语言

响应首部，提供更多有关响应的信息。

提供更多有关响应的信息，响应头部用于服务器向客户端提供更多的额外信息。

Server: Tiki-Hut/1.0		# 通知客户端本服务器的类型和版本

实体首部，描述主题的长度和内容，或者资源本身。

描述主体（HTTP报文体）的长度和内容，或者资源本身。

Content-Type: text/html; charset=iso-latin-1

首部延续行

长的首部可以分为多行提高可读性，多出来的每行至少有一个空格或者制表符，例如

// 长首部
Server：Test Server Version 1.0

// 首部延续行
Server：Test Server
    Version 1.0

Accept首部

accept首部告诉服务器客户端想要什么和不想要什么，服务器需要根据客户端的要求发送符合要求的内容。

accpet，允许的媒体类型。
accept-charset，允许的字符集。
accept-encoding，允许的编码方式。
accept-language，允许的语言。
te，允许的扩展传输编码。

条件请求首部

为请求加限制，服务端可以根据限制条件满足与否发送不同的内容。

expect，期望服务器的行为，例如：100 continue。
if-match，如果实体标记与文档当前的的实体标记相匹配，就获取这份文档。
if-modified-since，除非在某个指定的日期之后资源被修改过，否则限制这个请求。
if-none-match，如果提供的实体标记与当前文档的实体标记不相符，就获取文档。
if-range，允许对文档的某个范围进行条件请求。
if-unmodified-since，除非在某个指定日期之后资源没有被修改过，否则就限制这个请求。
range，如果服务器支持范围请求，就请求资源的指定范围。

安全请求首部

authorization，客户端自身认证数据。
cookie，客户端令牌。
cookie2，用来说明客户端支持的cookie版本。

代理请求首部

max-forward，将请求转发给其他代理或者网关的最大次数。
proxy-authorization，与客户端认证一样。
proxy-connection，与客户端一样。

实体缓存首部

etag，与此实体相关的实体标记。
expires，缓存的失效时间。
last-modified，实体最后一次被修改的日期和时间。

内容首部

content-base，解析实体中相对URL时的基础URL。
content-encoding，对实体执行的任意编码方式。
content-language，理解实体最适宜的语言。
content-length，实体的大小。
content-location，实体所处的位置。
content-MD5，实体的md5校验和
content-range，在整个资源中此实体表示的字节范围。

信息性首部

allow，列出了可以对此实体执行的请求方法。
location，告知客户端资源的位置（URL）

安全响应首部

proxy-authenticate，来自代理的对客户端的质询列表。
set-cookie，在客户端写入cookie。
set-cookie2，与set-cookie类似。
www-authenticate，来自服务器对客户端的质询列表

3.实体

实体的主体是HTTP报文的载荷，也就是HTTP要传输的内容，实体是可选的。

HTTP报文可以承载很多类型的数据：图片，视频，HTML文档，Javascript脚本，电子邮件等

实体的主体是HTTP报文的载荷，也就是HTTP要传输的内容，实体是可选的。

方法

HEAD

head方法只返回资源首部，使用head可以：

在不获取资源的情况下了解资源情况（content-type，content-length）；
验证资源是否存在；
验证资源是否被修改。

PUT

put方法的语义就是：让服务器用请求的主体部分创建一个用请求主体部分创建一个由所请求的URL命名的新文档，如果已经存在，那么替换。

TRACE

trace方法允许客户端在最终将请求发送到服务器时，看看它变成什么样子了。该方法一般用来验证请求是否按照预期穿过了某些代理。trace请求不能携带实体。

OPTIONS options方法可以询问服务器支持哪些功能，或者可以询问针对特定资源所支持的功能。

DELETE

delete方法就是请求服务器删除请求URL所指定的资源，当然，服务器不一定会这么做，因为HTTP规范允许服务器在不告知客户端的情况下撤销请求。

POST 向服务器输入数据，用它来支持HTML表单

GET 用于请求服务器发送某个资源

安全方法 HTTP规范定义了get和head为安全方法，这意味着get和head不会在服务器产生动作。

状态码

状态码为客户端提供了一种理解事物处理结果的便捷方式

3.1 100 ~ 199 信息性状态码

下面是HTTP/1.1已定义的信息性状态码：

100 continue，说明已经收到了请求的初始部分，请客户端继续。
101 switching protocols，说明服务器正在根据客户端指定，将协议切换成update首部指定的协议。

100 continue的目的是希望客户端在向服务器发送实体时先询问服务器是否接受这个实体，即客户端需要发送一个携带100 continue的expect首部，这个首部一般用在要传送大文件时，并且客户端不应该一直等待服务器返回100 continue后才发送实体，超过一定时间后，客户端应该直接发送实体。

3.2 200 ~ 299 成功状态码

下面列出了已定义的成功状态码：

200 ok
201 created，用于响应创建对象的请求，比如put，location为新创建对象的引用。
202 accept，请求已被接受，但是还未执行操作，实体部分应当包含对执行情况的描述，比如完成时间等信息。
203 non-authoritative information，请求的首部并非来自源端服务器，假设你的请求在请求链上被某个资源服务器响应了，可能返回这个状态码。
204 no content，没有实体的响应。
205 reset content，告诉浏览器清除页面中所有的HTML表单元素。
206 partical content，成功执行了一个range请求。

3.3 300 ~ 399 重定向状态码

重定向状态码要么时告知客户端使用替代位置来访问他们所感兴趣的资源（重定向），要么就提供一个替代的响应而不是资源的内容（缓存）。

300 multiple choices，客户端的一个请求实际指向多个资源时，服务器会返回这个状态码以及location列表让客户端选择。
301 moved permanently，永久重定向，location中为现在资源所处的URL。
302 found，临时重定向，location中为临时定位资源，并且会把post改为get请求。
303 see other，临时重定向，并且会把post改为get请求。
304 not modified，资源未修改。
305 use proxy，用来说明必须通过代理访问，代理放在location中
307 temporary redirect，临时重定向，不过不会修改请求方法，如果是以post请求，那么新的请求就是post。

其中302，303和307都是临时重定向，造成这种结果的原因是HTTP/1.1兼容HTTP/1.0。因为HTTP/1.0希望客户端收到302后，如果原请求是post那么新的请求将被改为get。HTTP/1.1则用303和307分别实现了修改请求方法和不修改请求方法的功能，而将302保留给HTTP/1.0以保证兼容性。