第二章 HTTP报文

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

报文流

HTTP报文是在HTTP应用程序之间发送的数据块。这些数据块以一些文本信息的元信息（meta-information）开头，这些信息描述了报文的内容及含义后面跟着可选的数据部分。这些报文在客户端、服务器和代理之间流动。术语”流入”、”流出”、”上游”、”下游”都是用来描述报文方向的。

报文流入源端服务器
HTTP使用术语流入和流出来描述事务处理(transaction)的方向。报文流入源端服务器，工作完成之后，会流回用户的Agent代理中。
图报文流入源端服务器并流回到客户端
报文向下游流动
HTTP报文会像河水一样流动。不管是请求报文还是响应报文，所有报文都会向下游流动。所有报文的发送者都在接收者的上游。

报文的组成结构

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

需要说明的是，尽管HTTP规范中说明应该用CRLF来表示行终止，但是稳健的应用程序也应该接受单个换行符作为行的终止。有些老的，或者是不完成的HTTP应用程序并不总是既发送回车符又发送换行符

实体的主体或报文的主体（或者称为主体）是一个可选的数据块。与起始行和首部不同的是，主体中可以包含文本或者二进制数据，也可以为空。

报文的语法

所有的HTTP报文都可以分为两类：请求报文（request message）和响应报文（response message）。
请求报文会向Web服务器请求一个动作。响应报文会将请求的结果返回给客户端。
请求报文和响应报文的基本报文结构相同。

请求报文的格式：

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

<entity-body>

响应报文的格式：

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

<entity-body>

对各部分的简要描述

方法（method）：
客户端希望服务器对资源执行的动作。是一个单独的词，比如GET、HEAD或POST。
请求URL（request-URL）：
命名了所请求资源，或者URL路径组件完整URL。如果直接与服务器进行对话，只要URL的路径组件是就资源的绝对路径，通常就不会有什么问题——服务器可以假定自己是URL的主机/端口。
版本（version）：
报文所使用的HTTP版本，其格式看起来是这样
HTTP/<major>.<minor>
其中主要版本号（major）和次要版本号都是整数。
状态码：
这三位数字描述了请求过程中所发生的情况。每个状态码的第一位数字都用于描述状态的一般类别（“成功”，“出错”等）。
原因短语：
数字状态码的可读版本，包含行终止序列之前的所有文本。原因短语只对人类有意义。
首部（header）
可以有零个或者多个首部，每个首部都包含一个名字，后面跟着一个冒号（：），然后是一个可选的空格，接着是一个值，最后是一个CRLF。首部是由一个空行（CRLF）结束的，表示了首部列表的结束和实体主体部分的开始。有些HTTP版本，比如HTTP/1.1，要求有效的请求或者响应报文中必须包含特定的首部。
实体的主体部分：
实体的主体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主体部分，有时，报文只是以一个CRLF结束。

假想的请求和响应报文

请求报文：
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!

注意，一组HTTP首部总是应该以一个空行（单个CRLF）结束，甚至即使没有首部和实体部分也应如此。但是由于历史原因，很多客户端和服务器都在没有实体的主体部分时，（错误地）省略了最后的CRLF。为了与这些流行但不符合规则的实现进行互通，客户端和服务器都应该接受那些没有最后那个CRLF的报文。

1.起始行

所有的HTTP报文都是以一个起始行作为开始。请求报文的起始行说明了要做些什么。响应报文的起始行说明发生了什么。

请求行：请求报文请求服务器对资源进行一些操作。
请求报文的起始行，或称为请求行，包含一个方法和一个请求URL，这个方法描述了服务器应该执行的操作，请求URL描述了要对哪个资源执行这个方法。请求行中还包含HTTP版本，用来告知服务器，客户端使用的是哪种HTTP。所有这些字段都由空格符分隔。
响应行：响应报文承载了状态信息和操作产生的所有结果数据，将其返回给客户端。
响应报文的起始行，或称为响应行，包含了响应报文使用的HTTP版本、数字状态码，以及描述操作状态的文本形式的原因短语。所有这些字段都由空格符进行分隔。
方法：请求的起始行以方法作为开始，方法用来告知服务器要做些什么。
HTTP规范中定义了一组常用的请求方法。

表常用的HTTP方法

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

并不是所有的服务器都实现了上表中的列出的所有7中方法。而且由于HTTP设计得易于扩展，所以除了这些方法之外，其他服务器可能还会实现一些自己的请求方法。这些附加的方法是对HTTP规范的扩展，因此被称为扩展方法。

状态码：方法是用来告诉服务器做什么事情的，状态码则是用来告诉客户端发生了什么事情。
状态码位于响应的起始行中。比如，在行HTTP/1.0 200 OK中，状态码就是200.
状态码实在每条响应报文的起始行中返回的。会返回一个数字状态和一个可读的状态。数字码便于程序进行差错处理，而原因短语则更便于人们的理解。

表状态码分类

整体范围	已定义范围	分类
100~199	100~101	信息提示
200~299	200~206	成功
300~399	300~305	重定向
400~499	400~415	客户端错误
500~599	500~505	服务器错误

当前的HTTP版本只为没类状态定义了几个代码。随着协议的发展，HTTP规范中会正式地定义更多的状态码。如果收到不认识的状态码，可能是有人将其作为当前协议的扩展定义的。可以根据其所处的范围，将它作为那个类别中一个普通的成员来处理。

比如，如果收到了状态码515（在状态码分类中所列5XX代码的已定义范围之外），就应该认为这条响应指出了服务器的错误，这是5XX报文的通用类别。

原因短语：
原因短语是响应起始行中的最后一个组件。它为状态码提供了文本形式的解释。比如，在行HTTP/1.0 200 OK中，OK就是原因短语。
版本号：
版本号会以HTTP/x.y的形式出现在请求和响应报文的起始行中。使用版本号的目的是为使用HTTP的应用程序提供的一种线索，以便互相了解对方的能力和报文格式。

注意：版本号不会被当做分数来处理。版本中的每个数字都会被当做一个单独的数字来处理。因此，在比较HTTP版本时，每个数字都必须单独进行比较，以便确定哪个版本更高。比如，HTTP/2.22就比HTTP/2.3版本要高，因为22比3大。

2.首部

HTTP首部字段向请求和响应报文中添加一些附加信息。本质上来说，它们只是一些名/值对的列表。

首部分类

首部类别	功能
通用首部	既可以出现在请求报文中，也可以出现在响应报文中
请求首部	提供更多的有关请求的信息
响应首部	提供更多的有关响应的信息
实体首部	描述主体的长度和内容，或者资源自身
扩展首部	规范中没有定义的新首部

每个HTTP首部都由一种简单的语法：名字后边跟着冒号（：），然后跟上可选的空格，再跟上字段值，最后一个是CRLF。

表常见首部实例

首部实例	描述
Date:Tue,30ct 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
Sercer: Test Server
    Version 1.0

在这个例子中，响应报文中包含了一个Server首部，其值被划分成了多个延续行。

3.实体的主体部分

HTTP报文的第三部分时可选的实体主体部分。实体的主体是HTTP报文的负荷。就是HTTP要传输的内容。HTTP报文可以承载很多类型的数字数据：图片、视频、HTML文档、软件应用程序、信用卡事务、电子邮件等。

方法

注意：并不是每个服务器都实现了所有的方法，即使是服务器实现了所有的这些方法，这些方法的使用很可能也是受限制的。例如支持DELETE方法和PUT方法的服务器可能并不希望任何人都能删除或者是存储资源。这些限制通常都是在服务器的配置中进行设置的，因此会随着站点和服务器的不同而有所不同。

1.安全的方法

HTTP定义了一组被称为安全方法的方法。GET方法和HEAD方法都被认为是安全的，这就意味着使用GET和HEAD方法的HTTP请求都不会产生什么动作。

不产生动作，在这里意味着HTTP请求不会在服务器上产生什么结果。例如，你在一家商店购物时，点击了“提交购买”按钮。点击按钮时会提交一个带有信用卡信息的POST请求，那么在服务器上，就会为你执行一个动作。在这种情况下，为购买行为支付信用卡就是所执行的动作。

安全方法并不一定是什么动作都不执行的（实际上这是由Web开发者决定的）。使用安全方法的目的就是允许HTTP应用程序开发者通知用户，什么时候会使用某个可能引发某些动作的不安全方法。在商店的例子中，你的Web浏览器可能会弹出一条警告消息，说明你正在用不安全的方法发起请求，这样可能会在服务器上引发一些事件。

2.GET

GET是最常用的方法，通常用于请求服务器发送某个资源。

3.HEAD

HEAD方法与GET方法的行为很类似，但是服务器在响应中只返回首部。不会反悔实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。使用HEAD，可以：

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

服务器开发者必须确保返回的首部与GET请求所返回的首部完全相同。

4.PUT

与GET从服务器读取文档相反，PUT方法会向服务器写入文档。有些发布系统允许用户创建Web页面，并用PUT直接将其安装到Web服务器上。
PUT方法的语义就是让服务器用请求的主体部分来创建一个由所请求的URL命名的新文档，或者，如果那个URL已经存在的话，就用这个主体来替代它。
因为PUT允许用户对内容进行修改，所以很多Web服务器都要求在执行PUT之前，用密码登录。

5.POST

POST方法起初是用来向服务器输出数据的。实际上，通常会用它来支持HTML的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方（比如，送到一个服务器网关程序中，然后由这个程序对其进行处理）。

6.TRACE

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

TRACE请求会在目的服务器端发起一个“环回”诊断。行程最后一站的服务器会弹回一条TRACE响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间HTTP应用程序组成的请求/响应链上，原始报文是否，以及如何被毁坏或修改过。

TRACE方法只要用于诊断，也就是说，用于验证请求是否如愿穿过了请求/响应链。它也是一种很好的工具，可以用来查看代理和其他应用程序对用户请求所产生的效果。

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

7.OPTIONS

OPTIONS方法请求WEB服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。
这为客户端应用程序提供了一种手段，使其不用实际访问哪些资源就能判定访问各种资源的最优方式。

8.DELETE

顾名思义，DELETE方法所做的事情就是请求服务器删除请求URL中所指定的资源。但是，客户端应用程序无法保证删除操作一定会被执行。因为HTTP规范允许服务器在不通知客户端的情况下撤销请求。

9.扩展方法

HTTP被设计成字段可扩展的，这样新的特性不会使老的软件失效了。扩展方法指的是没有在HTTP/1.1规范中定义的方法。服务器会为它所管理的资源实现一些HTTP服务，这些方法为开发者提供了一种扩展这些HTTP服务能力的手段。

表 Web发布扩展方法示例

方法	描述
LOCK	允许用户“锁定”资源——比如，可以在编辑某个资源的时候将其锁定，以防别人同时对其进行修改
MKCOL	允许用户创建资源
COPY	便于在服务器上复制资源
MOVE	在服务器上移动资源

并不是所有的扩展方法都是在正式规范中定义的，认识到这一点很重要。如果你定义了一个扩展方法，很可能大部分HTTP应用程序都无法理解。同样你的HTTP应用程序也可能会遇到一些其他应用程序在用的，而它并不理解的扩展方法。

在这些情况下，最好对扩展方法宽容一些。如果能够在不破坏端到端行为的情况下将带有未知方法的报文传递给下游服务器的话，代理会尝试着传递这些报文的。否则，它们会以501 Not Imple（无法实现）状态码进行响应。最好按照惯例“对所发送的内容要求严一点，对所接受的内容宽容一些”来处理扩展方法（以及一般的HTTP扩展）。

状态码

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

100~199——信息性状态码
HTTP/1.1向协议中引入了信息性状态码。这些状态码相对较新，由于对其复杂性和感知价值存在一些争论而受到限制。

表信息性状态码及短语

状态码	原因短语	含义
100	Continue	说明收到了请求的初始部分，请客户端继续。发送了这个状态码之后，服务器在收到请求之后必须进行响应。
101	Switching Protocols	说明服务器正在根据客户端的指定，将协议切换成Update首部所列的协议

100 Continue状态码尤其使人糊涂。它的目的是对这样的情况进行优化：HTTP客户端应用程序有一个实体的主体部分要发送给服务器，但是希望在发送之前查看一下服务器是否会接受这个实体。这可能会给HTTP程序员带来一些困扰，因此在这里进行了比较详细的讨论。（它如何与客户端、服务器和代理进行通信）

200~299——成功状态码
客户端发起请求时，这些请求通常都是成功的。服务器有一组用来表示成功的状态码，分别对应不同类型的请求。

表已定义的成功状态码

状态码	原因短语	含义
200	OK	请求成功，实体的主体部分包含了所请求的资源
201	Create	用于创建服务器对象的请求（比如PUT）。响应的实体部分中应该包含各种引用了已创建的资源的URL，Location首部包含的则是最具体的引用。服务器必须在发送这个状态码之前创建好对象。
202	Accepted	请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会完成这个请求；这只是意味着接受请求时，它看起来是有效的。服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计（或者包含一个指针，指向可以获取此信息的位置）
203	Non-Authoritative Information	实体首部包含的信息不是来自于源端服务器，而是来自于资源的一份副本。如果中间节点上有一份资源副本，但是无法或者没有对它所发送的与资源有关的元信息（首部）进行验证，就会出现这种情况。这种相应码并不是非用不可的，如果实体首部来自源端服务器，响应为200状态的应用程序就可以将其作为一种可选项使用。
204	No Content	响应报文中包含若干首部和一个状态行，但是没有实体的主体部分，主要用于在浏览器不转为显示新文档的前提下，对其进行更新（比如刷新一个表单页面）
205	Reset Content	另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中所有HTML表单元素
206	Partial Content	成功执行了一个部分或Range（范围）请求。客户端可以通过一些特殊的首部来获取部分或某个范围内的文档——这个状态码就说明范围请求成功了。206响应中必须包含Content——Range、Data以及ETag或Content——Location首部。

300~399

重定向状态码要么告知客户端使用替代位置来访问他们所感兴趣的资源，要么就提供一个替代的响应而不是资源内容。如果资源已经被移动，可发送一个重定向状态码和一个可选的Location首部来告知客户端资源已经被移动走了以及现在可以在哪里可以找到它。这样浏览器就可以在不打扰使用者的情况下，透明的转入新的位置。

表重定向状态码与原因短语

状态码	原因短语	含义
300	Multiple Choices	客户端请求一个实际指向多个资源的URL时会返回这个状态码，比如服务器上有个HTML文档的英语和法语版本。返回这个代码时会带有一个选项列表；这样的用户就可以选择他希望使用的那一项了，
301	Moved Permanently	在请求的URL已被移除时使用。响应的Location首部中应该包含资源现在所处的URL
302	Found	与301状态码类似；但是，客户端应该使用Location首部给出的URL来临时定位资源。将来的请求仍应使用老的URL
303	See Other	告知客户端应该用另一个URL来获取资源。新的URL位于响应报文的Location首部。其主要的目标是允许POST请求的响应将客户端定向到某个资源上去。
304	Not Modified	客户端可以通过所包含的请求首部，使其请求变成有条件的。如果客户端发起了一个条件GET请求，而最近资源没有被修改的话，就可以用这个状态码来说明资源未被修改。带有这个状态码的响应不应该包含实体的主体部分。
305	Use Proxy	用来说明必须通过一个代理来访问资源；代理的位置由Location首部给出。很重要的一点是，客户端是相对某个特殊资源来解析这条响应的，不能假定所有请求，甚至所有对持有所请求资源的服务器的请求都通过这个代理进行。如果客户端错误地让代理介入了某条请求，可能会引发破坏行为，而且会造成安全漏洞。
306	（未使用）	当前未使用
307	Temporary Redirect	与301状态码类似；但客户端应该使用Location首部给出的URL来临时定位资源。将来的请求应该使用老的URL。

状态码302、303和307状态码之间存在一些交叉。这些状态码的用法有着细微额差别，大部分差别都源于HTTP/1.0和HTTP/1.1应用程序对这些状态码处理方式不同。

当HTTP/1.0客户端发起一个POST请求，并在响应中收到302重定向状态码时，它会接受Location首部的重定向URL，并向那个URL发起一个GET请求（而不会像原始请求中那样发起POST请求）。

HTTP/1.0服务器希望HTTP/1.0客户端这么做——如果HTTP/1.0服务器收到来自HTTP/1.0客户端的POST请求之后发送了302状态码，服务器就期望客户端能够接受重定向URL，并向重定向的URL发送一个GET请求。

问题出在HTTP/1.1。HTTP/1.1规范使用303状态码来实现同样的行为（服务器发送303状态码来重定向客户端的POST请求，在它后面跟上一个GET请求）。

为了避开这个问题，HTTP/1.1规范指出，对于HTTP/1.1客户端，用307状态码取代302状态码来进行临时重定向。这样服务器就可以302状态码保留起来，为HTTP/1.0客户端使用了。

这样一来，服务器要选择适当的重定向状态码放入重定向响应中发送，就需要查看客户端的HTTP版本了。

400~499——客户端错误状态码
表客户端错误状态码及原因短语

状态码	原因短语	含义
400	Bad Request	用于告知客户端它发送一个错误地请求
401	Unauthorized	与适当的首部一同返回，在这些首部中请求客户端在获取对资源的访问权之前，对自己进行认证。
402	Payment Required	现在这个状态码还未使用，但是已经被保留，以作未来只用
403	Forbidden	用于说明请求被服务器拒绝了。如果服务器想说明为什么拒绝请求，可以包含实体的主体部分来对原因进行描述。但是这个状态码通常是在服务器不想说明拒绝原因是的时候使用的
404	Not Found	用于说明服务器无法找到所请求的URL。通常会包含一个实体，以便客户端应用程序显示给用户看
405	Method Not Allowed	发起的请求中带有所请求的URL不支持的方法时，使用此状态码。应该在响应中包含Allow首部，以告知客户端对所请求的资源可以使用哪些方法。
406	Not Acceptable	客户端可以指定参数来说明他们愿意接受什么类型的实体。服务器没有与客户端可接受的URL相匹配的资源时，使用此代码。通常，服务器会包含一些首部，以便客户端弄清楚为什么请求无法满足。
407	Proxy Authentication Requireed	与401状态码类似，但是用于要求对资源进行认证的代理服务器。
408	Request Timeout	如果客户端完成请求花费的时间太长，服务器可以会送此状态码，并且关闭连接。超时时长随服务器的不同有所不同，但是通常对所有的合法请求来说，都是够长的。
409	Conflic	用于说明请求可能在资源上引发的一些冲突。服务器担心请求会引发冲突时，可以发送此状态码。响应中应该包含描述冲突的主体。
410	Gone	与404类似，只是服务器曾经拥有过此资源。主要用于Web站点的维护，这样服务器的管理者就可以在资源被移除的情况下通知客户端了
411	Length Required	服务器要求在请求报文中包含Content-Length首部时使用。
412	Precondition Failed	客户端发起了条件请求，且其中一个条件失败了的时候使用，客户端包含了Except首部时发起的就是条件请求。
413	Request Entity Too large	客户端发送的实体主体部分比服务器能够或者希望处理的要大时，使用此状态码。
414	Request URL Too Long	客户端发送请求中的请求URL比服务器能够或者希望处理的要长时，使用此状码
416	Requested Range Not Satisfiable	请求报文所请求的是指定资源的某个范围，而此范围无效或无法满足时，使用此状态码。
417	Expectation Failed	请求的Expect请求首部包含了一个期望，但服务器无法满足此期望时，使用此状态码。如果有代理或其他中间应用程序有确切证据说明源端服务器会为某请求产生一个失败的期望，就可以发送这个响应状态码。

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

有时客户端发送了一条有效请求，但是服务器自身却出错了。这可能是客户端碰上了服务器的缺陷，或者服务器上的子元素，比如某个网关资源出了错。

代理尝试着代表客户端与服务器进行交流时，经常会出现问题。代理服务器会发布5XX服务器错误状态码来描述所遇到的问题。

表服务器错误状态码及原因短语

状态码	原因短语	含义
500	Internal Server Error	服务器遇到一个妨碍它为请求提供服务的错误时，使用此状态码
501	Not Implemented	客户端发起的请求超出服务器的能力范围（比如，使用了服务器不支持的请求方法）时，使用此状态码。
502	Bad Gateway	作为代理或网关使用的服务器从请求响应链的下一条链路上收到了一条伪响应（比如，它无法连接到其父网关）时，使用此状态码。
503	Service Unavailable	用来说明服务器现在无法为请求提供服务，但是将来可以。如果服务器知道什么时候资源会变为可用的，可以在响应中包含一个RetryAfter首部。
504	Gateway TimeOut	与状态码408类似，只是这里的响应来自一个网关或代理，它们在等待另一台服务器对其请求进行响应超时了。
505	HTTP Version Not Supported	服务器收到的请求使用了它无法或不愿意支持的协议版本时，使用此状态码。有些服务器应用程序会选择不支持协议的早期版本。

首部

首部和方法配合工作，共同决定了客户端和服务器能做什么事情。在请求和响应报文中都可以用首部来提供信息，有些首部是某种报文专用的，有些是更为通用的。

首部可以分为5个主要的类型

通用首部
这些是客户端和服务器都可以使用的通用首部。可以在客户端、服务器和其他应用程序之间提供一些非常有用的通用功能。比如Date首部就是一个通用首部，每一端都可以用它来说明构建报文的时间和日期：
Date: Tue, 3 Oct 1974 02:16:00 GMT
请求首部
从名字就可以看出来，请求首部就是请求报文特有的。它们为服务器提供了一些额外的信息，比如客户端希望接收什么类型的数据。例如，下例中的Accept首部就用来告知服务器客户端会接受与其请求相符的任意媒体类型：
Accept： */*
响应首部
响应报文有自己的首部集，以便为客户端提供信息（比如，客户端在与哪种类型的服务器进行交互）。例如，下例Server首部就用来告知客户端它在与一个版本1.0的Tiki-Hui服务器进行交互：
Server： Tiki-Hut/1.0
实体首部
实体首部指的是用于应对实体主体部分的首部。比如，可以用实体首部来说明实体主体部分的数据类型。
扩展首部
扩展首部是非标准的首部，由应用程序开发者创建，但还未添到已批准的HTTP规范中去。即使不知道这些扩展首部的含义，HTTP程序也要接受它们并对其进行转发。

报文流