http首部（Http权威指南）

报文
如果说HTTP是因特网的信使，那么HTTP报文就是它用来搬东西的包裹了。

3.1报文流
HTTP报文是HTTP应用程序之间发送的数据块。这些数据块以一些文本形式的元信息（meta-information）开头，这些信息描述了报文的内容以及含义，后面跟这可选的数据部分。
报文在客户端、服务器和代理之间流动。

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

3.1.2报文向下流流动
HTTP报文会像河水一样流动。不管是请求报文还是响应报文，所有报文都会向下流（downstream）流动。所有报文的发送者都在接受者的上流（upstream）。

3.2 报文的组成部分
HTTP报文是简单的格式化数据块。每一条报文都包含一条来自客户端的请求或者一条来自服务器的响应。
它们由三部分组成：对报文进行描述的起始行（start line）、包含属性的首部（header）块，以及可选的、包含数据的主体（body）部分。

起始行和首部就是由行分隔的ACII文本。每行都以一个由两个字符组成的行终止序列作为结束，包括一个回车符和一个换行符。需要指出的是，尽管HTTP规范中说明应该用CRLF来表示行终止，但稳健的应用程序也应该接受单个换行符作为行的终止

实体的主体或报文的主体是一个可选的数据块。与起始行和首部不同的是，主体中可以包含文本或二进制数据，也可以为空
例子：
起始行：HTTP/1.0 200 OK
首部： Content-Type : text/plain
Content-length : 19
主体： Hi ！ I'm a messagel

3.2.1 报文的语法
所有的HTTP报文都可以分为两类:请求报文（request message）和响应报文（response message）。请求报文向Web服务器请求一个动作。响应报文会将请求的结果返回给客户端。两种报文的格式相同。
例子：
请求：GET /specials/saw-blade.gif HTTP/1.0
Host: www.joes-hardware.com

响应：HTTP/1.0 200 OK
Content-Type : image/gif
Content-Length : 8572

主体内容
这是请求报文的格式：
<method> <request-URL> <version>
<headers>

<entity-body>
这是响应报文的格式（注意，只有起始行的语法有所不同）：
<version> <status> <reason-phrase>
<headers>

<entity-body>

对报文各个部分的描述：
方法（method）
客户端希望服务器对资源执行的动作，是一个单独的词，比如GET、HEAD或POST
请求URL（request-URL）
命名了所请求资源，或者URL路径组件的完整URL
版本（version）
报文所使用的HTTP版本，其格式看起来是这样的：
HTTP/<major>.<minor>
其中主要版本号（major）和次要版本号（minor）都是整数
状态码（status-code）
这三位数字描述了请求过程中所发生的情况。每个状态码的第一位数字都用于描述状态的一般类别（“成功”、“出错”等）
原因短语（reson-phrase）
数字状态码的可读版本，包含行终止序列之前的所有文本。只是用来描述，不影响结果
首部（header）
可以有0个或多个首部，每个首部都包含一个名字，后面跟这一个冒号:，然是一个可选的空格，接着是一个值，最后是一个CRLF。首部是由一个空行（CRLF）结束的，表示了首部列表的结束和实体主体部分的开始。有些HTTP版本，比如HTTP/1.1，要求有效的请求或者响应报文中必须包含特定的首部。
实体的主体部分（entity-body）
实体的主体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主体部分
例子：
请求： GET /test/hi-there.txt HTTP/1.1
Accept: text/*
Host: www.joes-hardware.com
响应： HTTP/1.0 200 OK
Content-Type: text/plain
Content-Length: 19

Hi! I'm a message!
3.2.2 起始行
所有的HTTP报文都以一个起始行做为开始。请求报文的起始行说明了要做些什么，响应报文的起始行说明发生了什么。
请求行:
请求报文请求服务器对资源进行一些操作。请求报文的起始行，或称为请求行。包含了一个方法和一个请求URL，这个方法描述了服务器应该执行的操作，请求URL描述了要对那个资源执行这个方法。请求行中还包含HTTP的版本，用来告知服务器，客户端使用的是那种HTTP。
所有的这些字段都由空格符分隔。在HTTP/1.0之前，并不要求请求行中包含HTTP版本号
响应行：
响应行报文承载了状态信息和操作产生的所有结果数据，将其返回给客户端。响应报文的起始行，或称为响应行，包含了响应报文使用的HTTP版本、数字状态码，以及描述操作状态的文本形式的原因短语。
这些字段都由空格分隔，在HTTP/1.0之前，并不要求在响应中包含响应行
方法：
请求的起始行以方法作为开始，方法用来告知服务器要做些什么，比如在行“GET/specials/saw-blade.gif HTTP/1.0”中，方法就是GET。
下表描述了7种这样的方法。注意，有些方法的请求报文中有主体，有些则无主体的请求。

方法 描述 是否包含主体
GET 从服务器获取一份文档 否
HEAD 只从服务器获取文档的首部 否
POST 向服务器发送需要处理的数据 是
PUT 将请求的主体部分存储在服务器上 是
TRACE 对可能经过代理服务器传送到服务器上的报文进行追踪 否
OPTIONS 决定可以在服务器上执行哪些方法 否
DELETE 从服务器上删除一份文档 否
并不是所有的服务器都实现了这7种方法，而且由于HTTP易于拓展，所以除了这些方法之外，其他服务器还可能实现一些自己的请求方法。
状态码
方法是用来告诉服务器做什么事的，状态码则用来告诉客户端，发送了什么事情。
状态码位于响应的起始行中。比如在行HTTP/1.0 200 OK 中，状态码就是200
可以通过三位数字代码对不同状态码进行分类。
整体范围 已定义范围 分类
100~199 100~101 信息提示
200~299 200~206 成功
300~399 300~305 重定向
400~499 410~415 客户端错误
500~599 500~505 服务器错误
原因短语
原因短语是响应起始行中的最后一个组件。它为状态码提供了文本形式的结束。比如在HTTP/1.0 200 OK中，OK就是原因短语。
原因短语和状态码是成对出现的。原因短语是状态码的可读版本。
版本号
版本号会以HTTP/x.y的形式出现在请求和响应报文的起始行中。为HTTP应用程序提供了一种将自己所遵循的协议版本告知对方的方式。高版本兼容低版本，注意版本高低比较版本号。注意次版本号是整数而不是小数。也就是说HTTP/2.22比HTTP/2.3大，因为22>3
3.2.3 首部
跟在请求行或响应行下面的是HTTP首部字段
HTTP首部字段向请求和响应报文中添加了一些附加信息。本质上来说，它们只是一些名/值对的列表。比如，下面的首部行会想Content-Length首部字段赋值19
Content-Length: 19
1、首部分类：
HTTP规范定义了几种首部字段。应用程序也可以随意发明自己所用的首部。HTTP首部可以分为以下几类：
1、通用首部
既可以出现在请求报文中，也可以出现在响应报文中。
2、请求首部
提供更多有关请求的信息
3、响应首部
提供更多有关响应的信息
4、实体首部
描述主体的长度和内容，或者资源本身
5、资源首部
规范中没有定义的新首部
每个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
首部延续行：
将长的首部行分为多行可以提高可读性，多出来的梅刚前面至少有一个空格或者一个制表符（Tab）。
例如：
HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
Version 1.0
3.2.4 实体的主体部分
HTTP报文的第三部分是可选的实体部分。实体的主体是HTTP报文的负荷。就是HTTP要传输的内容。
3.2.5 版本0.9的报文
HTTP版本0.9是HTTP协议的早期版本。是如今HTTP所拥有的请求及响应报文的鼻祖，但其协议要简单得多
HTTP/0.9 报文也由响应和请求组成，但请求中只包含方法和请求UR;，xi9angying中只包含实体。它没有版本信息，没有状态码或原因短语，也没有首部
3.3 方法
注意，并不是每个服务器都实现了所有的方法。如果一台服务器要与HTTP1.1兼容，那么只需要为其资源提供GET方法和HEAD方法就可以了。即使服务器实现了这些方法，这些方法的使用也可能是受限的。例如，支持DELETE方法或PUT方法的服务器可能不希望任何人能够删除或者存储资源。这些限制通常是在服务器的配置中进行设置的，可能随着站点和服务器的不同而有所不同。

3.3.1 安全方法
HTTP定义了一组被称为安全方法的方法。GET和HEAD方法都被认为是安全的，这就意味着使用GET或HEAD方法的HTTP请求都不会产生什么动作。
不产生动作，这里意味着HTTP请求不会在服务器上产生什么结果
使用安全方法并不一定是什么动作都不执行的（实际上，这是由Web开发者决定的），使用安全方法的目的是允许HTTP应用程序开发者通知用户，什么时候会使用某个可能引发某些动作的不安全方法。

3.3.2 GET
GET是最常用的方法。通常用于请求服务器发送某个资源。HTTP/1.1要求服务器实现此方法
3.3.3 HEAD
HEAD方法与GET方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对首部的资源进行检查。
使用HEAD，可以：
在不获取资源的情况下了解资源的情况（比如，判断类型）
通过查看响应中的状态码，看看某个对象是否存在
通过查看首部，测试资源是否被修改了
服务器开发者必须确保返回的首部与GET请求所返回的首部完全相同。遵循HTTP/1.1规范就必须实现HEAD方法。

3.3.4 PUT
与GET从服务器读取文档相反，PUT方法会向服务器写入文档。有些发布系统允许用户创建Web页面，并且用PUT直接将其安装到Web服务器上去。
PUT方法的语义就是让服务器用请求的主体内容来创建一个由所请求的URL命名的新文档，或者，如果那个URL已经存在的话，就用这个主体来替换它
3.3.5 POST
POST方法起初是用来向服务器输入数据的，通常会用它支持HTML的表单。
3.3.6 TRACE
客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或一些其他的应用程序。每个中间阶段都可能会修改HTTP请求。TRACE方法允许客户端最终将请求发送给服务器，看看它变成了什么样子。
TRACE请求会在目的服务器端发起一个“环回”诊断。行程最后一站的服务器会弹回一条TRACE响应，并在响应主体中携带它手袋的原始请求报文。这样客户端就可以查看在所有中间HTTP应用程序上组成的请求/响应链上，原始报文是否，以及如何被毁坏或修改过。
TRACE方法主要用于诊断！
TRACE请求也有缺点，它假定中间应用程序对各种不同的类型请求（不同的方法————GET、HEAD、POST等）的处理是相同的。很多HTTP应用程序会根据方法的不同做出不同的事情————例如代理可能将POST请求直接发送给服务器，而将GET请求发送给另一个HTTP应用程序（比如web缓存）

TRACE请求中不能带有实体的主体部分。TRACE响应的主体部分包含了响应服务器收到的请求的精确副本。

3.3.7 OPTIONS
OPTIONS方法请求Web服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法或者对某些特殊资源支持哪些方法。例如：
请求： OPTIONS * HTTP/1.1
Host: www.joes-hardware.com
Accept: *
响应：HTTP1.1 200 OK
Allow: GET, POST, PUT, OPTIONS
Context-length: 0
3.3.8 DELETE
顾名思义，DELETE方法所做的事情就是请求服务器删除请求URL锁指定的资源。但是客户端程序无法保证删除操作一定会被执行。因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。
3.3.9 拓展方法
HTTP被设计成字段可拓展的，这样新的特性就不会使老的软件失效了。

3.4 状态码
在前面所示，HTTP的状态码被分为5大类。
3.4.1 100~199————信息性状态码
状态码 原因短语 含义
100 Continue 说明收到了请求的初始部分，请客户端继续，发送了这个状态码之后，服务器在收到请求之后必须进行响应
101 Switching Protocols 说明服务器正在根据客户端的指定，将协议切换成Update首部锁列的协议
3.4.2 200~299————成功状态码
3.4.3 300~399 ————重定向状态码
3.4.4 400~499————客户端错误状态码
3.4.5 500~599————服务器错误状态码

3.5 首部
首部和方法配合工作，共同决定了客户端和服务器能做什么事情。
通用首部：
这些是客户端和服务求i都可以使用的通用首部。如：
Date: Tue, 3 Oct 1974 02:16:00 GMT
请求首部
从名字中就可以知道，请求首部是请求报文特有的。例如Accept首部用来告知服务器客户端会接受的媒体类型
Accept: */*
响应首部
相应报文有自己的首部集，以便为客户端提供信息。例如，客户端在与那种类型的服务器进行交互。
Server: Tiki-Hut/1.0
实体首部
实体首部指的是应对实体主体部分的首部。比如，可以用实体首部来说明实体主体部分的数据类型。
Content-Type: text/html; charset=iso-latin-1
扩展首部
扩展首部是非标准的首部，由应用程序开发者创建，但未添加到已批准的HTTP规范中去。即使不知道这些扩展首部的含义，HTTP程序也要接受他们并对其进行转发。