http学习 1-3 chapter3-报文
如果说HTTP是因特网的信使，那么HTTP报文就是它用来搬东西的包裹了。
- 报文是如何流动的。
- HTTP报文的三个组成部分（起始行、首部和实体的主体部分）
- 请求和响应报文之间的区别
- 请求报文支持的各种功能（方法）
- 和响应报文一起返回的各种状态码
- 各种各样的HTTP首部都是用来做什么的。
3.1 报文流
HTTP报文是HTTP应用程序之间的发送的数据块。这些数据块以一些文本形式的元信息（meta-information）开头，这些信息描述了报文的内容及含义，后面跟着可选的数据部分。
3.1.1 报文流入源端服务器
HTTP使用属于 流入（inbound） 和流出（outbound）来描述事务处理（transaction）的方向。报文流入源端服务器，工作完成后，会流回到用户的Agent代理中。
3.1.2 报文向下游流动
所有报文都会向下游（downsteam）流动，所有的报文发送者都在接受者的上游（upstream）。
3.2 报文的组成部分
HTTP报文是简单的格式化数据块。每条报文都包含一条来自客户端的请求或者来自服务器的相应。他们有三个部分组成，对报文进行描述的起始行（start line）,包含属性的首部（header）快，以及可选的包含数据额主体（body）块。
起始行和首部就是由行分隔的ASCII文本。每行都已一个由两个字符组成的航中智序列作为结束，其中包括一个回城符（ASCII码13）和一个换行符（ASCII码 10）.CRLF
实体的主体或报文的主体是一个可选的数据块。与起始行和首部不同的是主体中可以包含文本或二进制数据，也可以为空。
3.2.1 报文的语法
所有的HTTP报文都可以分为两类：请求报文（request message）和相应报文（response message）。
请求报文的格式：
<method> <request-URL> <version>
<headers>
<entity-body>
相应报文格式
<version> <status> <reason-phase>
<headers>
<entity-body>
下面是对各部分的简要描述：
- 方法(method)
客户端希望服务器对资源执行的动作。是一个单独的词，GET HEAD POST
- 请求URL(request-URL)
命名了所请求资源、或URL路径组件的完整URL。
- 版本(version)
报文所使用的HTTP版本，其格式看起来是这样的：
HTTP/<major>.<minor>
主要版本号（major）次要版本号（minor）都是整数
- 状态码(status)
三位数字描述了请求过程中所发生的情况。每个状态码的第一位数字都用于描述状态的一般类别（“成功”，“出错”）
- 原因短语(reason-phase)
数字状态吗的可读版本，包含行终止序列之前的所有文本。
- 首部(headers)
可以偶零个或多个首部，没个首部都包含了一个名字，后面跟着一个（：），然后是一个可选的空格，接着是一个值，最后是一个CRLF，首部是有一个空行额CRLF结束的。表示了首部列表的结束和实体主体部分的开始。
- 实体的主体部分(entity-body)
实体的主体部分包含一个由任意数据组成的数据块，并不是所有的报文都包含实体的主体部分。
3.2.2 起始行
所有的HTTP报文都以一个起始行作为开始，请求报文的起始行说明了要做些什么。相应报文的起始行说明发生了什么。
- 1. 请求行
请求报文请求服务器对资源进行一些操作，包含了一个方法和一个请求URL，还包含了HTTP的版本。所有这些字段都由空格符分隔。
- 2. 响应行
相应保温承载了状态信息和操作产生的所有结果数据。包含了相应报文使用的HTTP版本、数字状态吗以及描述操作状态的文本形式的原因短语，都有空格分隔
- 3. 方法
请求起始行以方法作为开始，方法用来告知服务器要做些什么。
n GET 从服务器获取一份文档 否
n HEAD 只从服务器获取文档的首部 否
n POST 向服务器发送需要处理的数据 是
n PUT 将请求的主体部分存储在服务器上 是
n TRACE 对可能经过代理服务器传送到服务器上的报文进行追踪 否
n OPTIONS 决定可以在服务器上执行哪些方法 否
n DELETE 从服务器上删除一份文档 否
- 4. 状态码
方法使用来告诉服务器做什么，状态码则是用来告诉客户端发生了什么事情。
状态码是在每条相应报文中的起始行返回的。会返回一个数字状态和一个可读的状态。数字吗便于程序进行差错处理，而原因短语则跟他便于人们理解。
n 整体范围 已定义范围 分类
n 100 ~ 199 100 ~ 101 信息提示
n 200 ~ 299 200 ~206 成功
n 300 ~ 399 300 ~305 重定向
n 400 ~ 499 400 ~ 415 客户端错误
n 500 ~ 599 500 ~505 服务器错误
常见状态码
200 OK 成功。请求的所有数据都在响应主体中
401 Unauthorized 需要输入用户名和密码
404 Not Found 服务器无法找到锁清秋的URL对应的资源
- 5. 原因短语
原因短语和状态码是成对出现的。原因短语是状态码的可读版本，应用程序开发者将其传送给用户，用以说明在请求期间发生了什么情况。
- 6. 版本号
版本号说明了应用程序支持的最高HTTP笨笨。
注意：版本号不会被当作分数来处理，版本中的每个数字都会被当做一个单独的数字来处理。因此比较HTTP版本是，没个数字必须单独进行比较，以便确定那个版本更高，比如： HTTP/2.22 就比 HTTP/2.3的版本要搞，因为 22比3大。
3.2.3 首部
跟在起始行的后面就是零个，一个或多个HTTP首部字段。
HTTP首部字段想请求和相应报文中添加了一些附加信息。本质上来说，他们只是一些名/值对的列表。
1.首部分类
HTTP规范定义了几种首部字段。应用程序也可以随意发明自己所用的首部。HTTP首部可以分为一下几类。
- 通用首部
既可以出现在请求报文中，也可以出现在响应报文中
- 请求首部
提供更多有关请求的信息
- 响应首部
提供更多有关相应的信息
- 实体首部
描述主体的长度和内容，或者资源自身
- 扩展首部
规范中没有定义的新首部
每个HTTP首部都有一种简单的语法：名字后面跟着冒号（：），然后跟上可选的空格，再跟上字段值，最后是一个CRLF。
常见的首部实例：
Date: Tue,3Oct 1997 02:16:03 GMT 服务器产生响应的日期
Content-length:15040 实体的主体部分包含了15040字节的数据
Content-type:image/gif 实体的主体部分是一个GIF图片
Accept:image/gif,image/jpeg,text/html 客户端接GIF图片和JPEG图片以及HTML
2．首部延续行
将长的首部行分为多行可以提高可读性，多出来的每行前面至少要有一个空格或制表符。
3.2.4 实体的主体部分
HTTP报文可以承载很多类型的数字数据：图片、视频、HTML文档，软件应用程序、信用卡事务，电子邮件等。
3.2.5 版本0.9的报文
HTTP版本0.9是HTTP协议的早期版本。是当今HTTP所拥有的请求及响应报文的鼻祖。
3.3 方法
并不是每个服务器都实现了所有的方法
3.3.1 安全方法
HTTP定义了一组被称为安全方法的方法，GET方法和HEAD方法都被认为是安全的，这就意味着使用GET或者HEAD方法的HTTP请求都不会产生什么动作。
不产生动作，在这里意味着HTTP请求不会在服务器上产生什么结果。使用安全方法的目的就是允许HTTP应用程序开发者通知用户，什么时候会使用某个可能已发某些动作的不安全方法。
3.3.2 GET
GET是最常用的方法，通常用于请求服务器发送某个资源。
3.3.3 HEAD
不会返回实体的主体部分，这就允许客户端在未获取司机资源的情况下，对资源的首部进行检查。使用HEAD，可以：
在不获取自愿的情况下列奥接资源的情况；
通过查看响应中的状态码，看看某个对象是否存在。
通过查看首部，测试资源是否被修改了
3.3.4 PUT
余GET从服务器读取文档相反，PUT方法会向服务器写入文档。因为PUT允许用户对内容进行修改，所以很多Web服务器都要求在执行PUT之前，用密码登录。
3.3.5 POST
POST方法起初是用来向服务器输入数据的，实际上，通常会用它来支持HTML的表单。
3.3.6 TRACE
客户端发起一个请求是，这个请求可能要穿过防火墙，代理、网关或其它一些应用程序。没个中间节点都可能修改原始的HTTP请求，TRACE方法允许客户端在最终将请求发送个服务器是，看看他变成了什么样子。
3.3.7 OPTIONS
OPTIONS方法请求Web服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。
3.3.8 DELETE
DELETE方法所做的事情就是请服务器伤处请求URL所指定的资源。但是客户端应用程序无法保证删除操作一定会被执行，因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。
3.3.9 扩展方法
HTTP被设计成字段可扩展的，这样新的特性就不会使老的软件失效了。
在这些情况下，最好对扩展方法宽容一些，如果能够在不破坏端到端行为的情况下将带有位置方法的报文传递给下游服务器的话，代理会尝试着传递这些报文的。否则，他们会议501NotImplement状态码进行相应。最好按惯例“对所发送的内容要求严一点，对所接受的内容宽容一些”来处理扩展方法。
3.4 状态码
状态码为客户端提供了一种理解事务处理结果的便捷方式。尽管没有实际的规范对原因短语的确切文本进行说明。
3.4.1 100 ~199 – 信息性状态码
HTTP/1.1 向协议中引入了信息性状态码。
100 continue
101 Switching Protocols
1.客户端与100 Continue
从很多方面来看，100 Continue都是一种优化。客户端应用程序只有在避免向服务器发送一个服务器无法处理或使用的大实体时，才应该使用100Continue。
2.服务器端与100Continue
如果服务器接收到了这个请求，会用100Continue响应或一条错误码来进行响应。
出于某种原因，服务器在有机会发送100Continue响应之前就收到了部分的实体，就说明客户端已经决定了继续发送数据了，这样服务器就不需要发送这个状态码了。
3.代理与100Continue
代理需要作出根据自身的代理情况作出判断，处理100Continiue
代理维护一些有关吓一跳服务器机器所支持的HTTP版本的状态信息是有好处的，这样他们就可以更好地处理收到的那些带有100Continue期望的请求了。
3.4.2 200 ~299---成功状态码
客户端发起请求时，这些请求通常都是成功的。服务器有一组用来表示成功的状态吗分别对应于不同类型的请求。
状态码 原因短语 含义
|
200 |
OK |
请求没问题的，实体的主体部分包含了所请求的资源 |
|
201 |
Created |
用于创建服务器对象的请求（比如:PUT）。响应的实体主体部分中应该包含各种引用了以创建的资源的URL，location首部包含的则是最具体的引用。服务器必须在发送这个状态吗之前创建好对象 |
|
202 |
Accepted |
请求已被接受，单服务器还未对其执行任何动作。不能保证服务器会完成这个请求，这只是意味着接受请求时，他看起来是有效的。服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计。 |
|
203 |
Non-authoritative Information |
实体首部包含的信息不是来自于源端服务器，而是来自资源的一份副本，如果中间节点上有一份资源副本，但无法或者没有对她所发送的与资源有关的元信息尽心验证就会出现这种情况。 |
|
204 |
No Content |
响应报文中包含若干首部和一个状态航，但没有实体的主体部分，主要用于在浏览器不转为显示新文档的情况下，对其进行更新 |
|
205 |
Reset Content |
另一个主要用于浏览器的代码，负责告知浏览器清除当前页面中的所有HTML表单元素 |
|
206 |
Partial Content |
成功执行了一个部分或range请求，稍后我们会看到，客户端可以通过一些特殊的首部来获取部分或某个范围内的文档 这个状态码就说明范文请求成功了 |
|
|
|
|
3.4.3 300~399 重定向状态吗
重定向状态码要门告知客户端使用替代位置来访问他们所感兴趣的资源，要么就提供一个替代的相应而不是资源的内容。
3.4.4 400~499 客户端错误状态吗
有时客户端会发送一些服务器无法处理的东西，比如格式错误的请求报文，或者求常见的是，请求一个不存在的URL。
3.4.5 500~599
有事客户端发送了一条有效请求，服务器自身却出多了，这可能是客户端碰上了服务器的缺陷，或者服务器上的子元素，比如某个网关资源出了错。
3.5首部
首部和方法配合工作，共同决定了客户端和服务器能做什么事情。在请求和相应报文中都可以用首部来提供信息，有些首部是某种报文专用的。有些瘦不则更通用一些，
- 通用首部
- 请求首部
- 相应首部
- 实体首部
- 扩展首部
3.5.1 通用首部
有些首部提供了与报文相关的最基本的信息。他们被称为通用首部。
|
首部 |
描述 |
|
Connection |
允许客户端和服务器指定与请求/响应链接有关的选项 |
|
Date |
提供日期和时间标志，说明报文是什么时间创建的 |
|
MIME-Version |
给出了发送端使用的MIME版本 |
|
Trailer |
如果报文采用了分块传输编码（chunked transfer encoding）方式，就可以用这个首部列出位于报文拖挂（trailer）部分的首部集合 |
|
Transfer-encoding |
告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式 |
|
Update |
给出了发送端可能想要升级使用的新版本或协议 |
|
Via |
显示了报文经过的中间节点（代理，网关） |
通用缓存首部
HTTP/1.0 引入了第一个允许HTTP应用程序缓存对象本地副本的首部，这样就不需要总是直接从源端服务器获取了。
Cache-Control 用于随报文传送缓存指示
Pragma 另一种随报文传送指示的方式，但并不专用于缓存
3.5.2 请求首部
请求首部是只在请求报文中有意义的首部。用于说明是谁或什么在发送请求，请求源自何处，或者客户端的喜好及能力。
|
首部 |
描述 |
|
Client-IP |
提供了运行客户端的机器的IP地址 |
|
Prom |
提供了客户端用户的E-mail地址 |
|
Host |
给出了接受请求的服务器的主机名和端口号 |
|
Referer |
提供了包含当前请求URI的文档的URL |
|
UA-Color |
提供了于客户端显示器的显示颜色有关的信息 |
|
UA-CPU |
给出了客户端CPU的类型或制造商 |
|
UA-Disp |
提供了于客户端显示器能力有关的信息 |
|
UA-os |
给出了运行在客户端机器上的操作系统名称及版本 |
|
UA-Pixels |
提供了客户端显示器的像素信息 |
|
User-Agent |
将发起请求的应用程序名称告知服务器。 |
- 1. Accept首部
Accept首部微客户端提供了一种将其喜欢喝能力告知服务器的方式。
Accept 告诉服务器能够发送哪些媒体类型
Accept-Charset 告诉服务器能够发送那些字符集
Accept-Encoding 告诉服务器能够发送哪些编码方式
Accept-Language 告诉服务器能够发送哪些语言
TE 告诉服务器可以使用那些扩展传输编码
- 2. 条件请求首部
有时客户端希望为请求加上某些限制。通过条件请求首部，客户端就可以为请求加上这种限制，要求服务器在对请求进行响应之前确保某个条件为真。
Expect 允许客户端列出某请求作要求的服务器行为
If-Match 如果实体标记与稳当当前的实体标记向匹配，就获取这份文档
If-Modified-Since 除非在某个指定的日期之后资源被修改过，否则就限制这个请求。
If-None-Match 如果提供的实体标记与当前文档的实体标记不相符，就获取文档
If-Range 允许对稳胆的某个范围进行条件请求
If-Unmodified-Since 除非在某个指定日期之后资源没有被修改过，否则就限制这个请求
Range 如果服务器支持范围请求，就请求资源的指定范围
- 3. 安全请求首部
HTTP本身就支持一种简单的机制，可以对请求进行质询/相应认证。这种机制要求客户端在获取特性的资源之前先对自身进行认证，这样就可以是事务稍微安全一些。
Authorization 包含了客户端提供给服务器，一边对其自身进行认证的数据
Cookie 客户端用它向服务器传送一个令牌---它并不是真正的安全首部， 隐含了安全功能
Cookie2 用来说明请求段支持的cookie版本
- 4. 代理请求首部
随着因特网上代理的普遍应用，人们定义了几个首部来协助其更好地工作。
Max-Forward 在通往源端服务器的路径上，经请求转发给其他代理或网关的最大次数—与TRACE方法一同使用
Proxy-Authorization 与Authorization首部相同，单这个手部是在与代理进行认证是使用的。
Proxy-Connection 与Connection首部相同，但这个首部是在与代理建立连接时使用的。
3.5.3 响应首部
相应保温有自己的相应瘦不及。相应首部微客户端提供了一些额外信息，比如谁在发送相应相应这的功能。甚至与相应相关的一些特殊指令。这些受不有助于客户端处理响应。殡改将来发起更好地请求。
|
首部 |
描述 |
|
Age |
响应持续时间 |
|
Public |
服务器为其资源支持的请求方法列表 |
|
Retry-After |
如果资源不可用的话，在此日期活时间重试 |
|
Server |
服务器应用程序软件的名称和版本 |
|
Title |
对HTML文档来说就是HTML文档的远端给出的标题 |
|
Warning |
比原因短语中更详细一些的警告报文 |
- 1. 协商首部
- 2. 安全响应首部
3.5.4 实体首部
有很多首部可以用来藐视HTTP报文的负荷
实体首部提供了有关实体机器内容的大量信息，从有关对象类型的信息，到能够对资源使用的各种有小的请求方法。总之，实体首部可以告知报文的及受着他在对什么进行处理
- 1. 内容首部
内容首部提供了与实体内容有关的特定信息 ，说明了其类型，尺寸以及处理它所需的其他有用信息。
- 2. 实体缓存首部
