报文流

报文的组成部分

报文语法

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 ServerVersion 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以保证兼容性。

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

已定义客户端错误状态码：

400 bad request，错误的请求。
401 unauthorized，未认证，和关于认证的首部一起返回。
402 payment required，保留。
403 forbidden，服务器拒绝了，并且不想告诉你拒绝的理由
404 not found，资源或者程序不存在，通常会在实体中告诉客户端具体问题。
405 method not allowed，该方法不被允许，在allowed首部中应该说明允许的方法。
406 not acceptable，服务器没有该URL相关的指定类型的资源，即客户端的首部的accept字段中包含的类型服务器没有。
407 proxy authentication required，要求对资源进行认证的代理服务器。
408 request timeout，如果客户端长时间未完成该请求，那么可以发送此状态码并关闭链接。
409 conflict，请求可能在资源上引发冲突。
410 gone，表示服务器曾经拥有该资源，但是现在没有了。
411 lenth required，表示服务器需要客户端带上content-length首部。
412 precondition failed，客户端包含了expect首部的请求成为条件请求，当条件不满足时，返回该状态码。
413 request entity too large，客户端发送的实体超过了服务器要求的长度。
414 request uri too long，客户端请求的URL太长了！
415 unsupported media type，服务器无法理解的媒体类型。
416 request range not satisfiable，请求指定的范围不满足。
417 expectation failed，请求的expect无法满足。

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

已定义的服务器错误状态码：

500 internal server error，服务器内部错误。
501 not implement，超出服务器能力范围。
502 bad gateway，代理或者网关无法连接到下一级网关（父级网关）。
503 service unavailabe，服务器现在不可用，但是未来可能可用，可以返回一个首部retry-after。
504 gateway timeout，和408 request timeout差不多，但是超时问题出现在代理或者网关上
505 http version not supported，服务器不支持或者不想支持该协议版本。

《HTTP权威指南》----HTTP报文相关推荐

Http权威指南学习研究
学习时间: 该学习:第六章 6.6小节加油 185页 2017年5月15日15:13:00 今天任务: 看完前两章节: ...
《HTTP权威指南》– 5.Web服务器
Web服务器概念: 实现了HTTP和相关的TCP连接处理,负责管理Web服务器提供的资源,以及对Web服务器的配置.控制及扩展方面的管理. 各种不同的形式: 通过软件Web服务器:运行在标准的.有网络 ...
《HTTP权威指南》 – 11.验证码和新鲜度
服务器应当告知客户端能够将内容缓存多长时间,在这个时间内就是新鲜的.服务器可以用这两个首部之一来提供信息: Expires(过期) Cache - Control(缓存控制) Expires首部规定 ...
《http权威指南》读书笔记14
概述最近对http很感兴趣,于是开始看<http权威指南>.别人都说这本书有点老了,而且内容太多.我个人觉得这本书写的太好了,非常长知识,让你知道关于http的很多概念,不仅告诉你怎么做 ...
《Netty权威指南》笔记 —— 第二十、二十一、二十二, 二十三章
<Netty权威指南>笔记--Netty高级特性第20章 Netty架构剖析 Reactor通信调度层职责链 ChannelPipeline 业务逻辑编排层关键架构质量属性高性能 ...
Kubernetes权威指南（下）
Phineas # Kubernetes权威指南<Kubernetes权威指南>第5版勘误:https://github.com/kubeguide/K8sDefinitiveGuide- ...
读HTTP权威指南的体会
国庆期间,我读了HTTP权威指南一书,现在我把总节为大家讲一下: Web 浏览器.服务器和相关的Web 应用程序都是通过HTTP 相互通信的.HTTP 是现代全球因特网中使用的公共语言. 是对HTT ...
《HTTP权威指南》摘要
目录前言第一章 HTTP 概述第二章 URL 与资源第三章 HTTP 报文报文流状态码 100~199:信息提示 200~299:成功 300~399:重定向 400~499:客户端错误 ...
计算机网络和http权威指南读书笔记
计算机网络笔记网络层网络层向上提供无连接的,尽最大努力交付的数据报服务网络层不提供数据质量承诺物理层使用的中间设备叫转发器repeater 数据链路层叫网桥bridge 网络层叫路由器rout ...
HTTP权威指南读书笔记
<<HTTP权威指南>>读书笔记第一部分:Web的基础第1章:HTTP概述主要内容 1.什么是HTTP 2.HTTP的基本组件 HTTP HTTP:HTTP(Hypert ...

《HTTP权威指南》----HTTP报文

报文流

报文的组成部分

报文语法

1.起始行

2.首部

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

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

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

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

首部延续行

Accept首部

条件请求首部

安全请求首部

代理请求首部

实体缓存首部

内容首部

信息性首部

安全响应首部

3.实体

方法

状态码

3.1 100 ~ 199 信息性状态码

3.2 200 ~ 299 成功状态码

3.3 300 ~ 399 重定向状态码

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

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

《HTTP权威指南》----HTTP报文相关推荐

最新文章

热门文章