http报文介绍

一、介绍       

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

        起始行和首部就是由行分隔的ASCII文本。每行都以一个由两个字符组成的行终止序列作为结束，其中包括一个回车符(0x0D)和一个换行符(0x0A)，这个行终止序列可以写作CRLF。实体的主体或报文的主体（或者就称为主体）是一个可选的数据块。与起始行和首部不同的是，主体中可以包含文本或二进制数据，也可以为空。

图1 简单的响应报文实例

        上图给出了一个简单的起始行、首部和主体的例子。

        所有的http报文都可以分为两类：请求报文和响应报文。请求报文会向web服务器请求一个动作，响应报文会将请求的结果返回客户端。请求和响应报文的基本报文结构相同。

        请求报文的格式为：

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

<entity-body>

        响应报文的格式为（只有起始行的语法和请求报文不相同）：

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

<entity-body>

        下面是对各部分的简要描述：

• method（方法）：客户端希望服务器对资源执行的动作。是一个单独的词，比如GET，HEAD或POST

• requset-URL（请求URL）：命名了所请求资源，或者URL路径组件的完整URL。相对路径也是可以的。

• version（版本）：报文所使用的http版本，格式是这样的：HTTP/<major>.<minor>

• status-code（状态码）：由三位数字组成，描述了请求过程中所发生的情况。每个状态码的第一位数字都用于描述状态的一般类别（“成功”或“错误”）。

• reason-phrase（原因短语）：数字状态码的可读版本，包含终止序列之前的所有文本。原因短语只对人类有意义，比如说，HTTP/1.0 200 NOT OK和HTTP/1.0 200 OK中虽然原因短语不同，但同样会被当作成功指示处理。

• header（首部）：可以有零个或多个首部，每个首部都包含一个名字，后面跟着一个冒号，然后是一个可选的空格，接着是一个值，最后是一个CRLF。首部是由一个空行（CRLF）结束的，表示了首部列表的结束和实体主体部分的开始。有些版本中，比如HTTP/1.1，要求有效的请求或相应报文中必须包含特定的首部。

• entity-body（实体的主体部分）实体的主体部分包含一个由任意数据组成的数据块。并不是所有的报文都包含实体的主体部分。

        下面是一个请求和响应报文的示例。

图2 请求报文和响应报文

二、起始行、首部和主体的详细介绍

1. 起始行

        (1) 请求行

        请求报文的起始行，或称为请求行，包含了一个方法和一个请求URL，以及一个http版本。这些字段都由空格符分隔。在图2的请求报文中，请求方法为GET，请求URL为/test/hi-there.txt，版本为HTTP/1.1，在HTTP/1.0之前，并不要求请求行中包含http版本号。

        (2) 响应行

        响应报文承载了状态信息和操作产生的所有结果数据。响应报文的起始行，或称响应行，包含了响应报文使用的http版本，数字状态码，以及描述操作状态的文本形式的原因短语。所有这些字段都由空格符进行分割。在HTTP/1.0之前，并不要求在响应中包含响应行。

        (3) 方法

        请求的起始行以方法作为开始，方法用来告知服务器要做些什么。下面是一些常用的http方法。

                                表1 常用的http方法

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

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

        (4) 状态码

        方法用来告诉服务器要做什么事，状态码则告诉客户端发生了什么事。客户端向一个http服务器发送请求报文时，会发生很多事。有可能请求会顺利完成，也有可能找不到所请求的文件，或者没有访问资源的权限，或者资源被移到了其他地方。

        状态码是在每条响应报文的起始行中返回的。会返回一个数字状态和一个可读的状态。数字码便于程序进行差错处理，而原因短语则更便于人们理解。

        1开头的状态码用于信息提示，2开头的状态码表示成功，3开头的表示资源被转移走了，4开头的表示客户端的请求出错了，5开头的状态码表示服务器错误。

        (5) 原因短语

        原因短语是响应起始行中的最后一个组件，它为状态码提供了文本形式的解释。原因短语和状态码是成对出现的。原因短语是状态码的可读版本，用于说明在请求期间发生了什么情况。

        (6) 版本号

        版本号的格式是HTTP/x.y，为http应用程序提供了一种将自己所遵循的协议版本告知对方的方式。使用版本号的目的是为使用http的应用程序提供一种线索，以便互相了解对方的能力和报文格式。

2. 首部

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

        (1) 首部分类

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

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

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

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

• 扩展首部：规范中没有定义的新首部。

                                表2 常见的首部实例

首部实例	描述
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) 首部延续行

        将长的首部行分为多行可以提高可读性，多出来的每行前面至少要有一个空格或制表符。

        例如：

HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
    Version 1.0

        在这个例子中，响应报文里包含了一个Server首部，其值被划分成个多个延续航。该首部的完整值为Test Server Version 1.0。

3. 实体的主体部分

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

三、基本的http方法

        并不是每个服务器都实现了所有的方法。如果一台服务器要与http 1.1 兼容，那么只要为其资源实现GET方法和HEAD方法就可以了。即使服务器实现了所有的这些方法，这些方法的使用很可能也是受限的。例如，支持DELETE方法或PUT方法的服务器可能并不希望任何人都能够删除或存储资源。这些限制通常都是在服务器的配置中进行设置的，因此会随着站点和服务器的不同而有所不同。

1. 安全方法

        http定义了一组被称为安全方法的方法。GET方法和HEAD方法都被认为是安全的，这就意味着使用GET或HEAD方法的http请求都不会产生什么动作。POST请求则会产生某种动作。安全方法并不一定是什么动作都不执行的，这主要由开发者决定。

2. GET

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

图3 GET示例

3. HEAD

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

• 在不获取资源的情况下了解资源的情况（比如，判断其类型）。

• 通过查看响应中的状态码，看看某个对象是否存在。

• 通过查看首部，测试资源是否被修改了。

        服务器开发者必须确保返回的首部与GET请求所返回的首部完全相同。遵循HTTP/1.1规范，就必须实现HEAD方法。

图4 HEAD示例

4. PUT

        与GET从服务器读取文档相反，PUT方法会向服务器写入文档。有些系统允许用户创建Web页面，并用PUT直接将其安装到web服务器上去。

图5 PUT示例

        PUT方法的语义就是让服务器用请求的主体部分来创建一个由所请求的URL命名的新闻的，或者，如果那个URL已经存在的话，就用这个主体来替代它。因为PUT允许用户对内容进行修改，所以很多web服务器都要求在执行PUT之前，用密码登陆。

5. POST

        POST方法起初是用来向服务器输入数据的（POST是发送，PUT是存储）。实际上，通常会用它来支持HTML的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方。

图6 POST示例

6. TRACE

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

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

图7 TRACE示例

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

        尽管TRACE可以很方便地用于诊断，但它确实也有缺点，它假定中间应用程序对各种不同类型的请求（GET、HEAD、POST等）的处理是相同的。很多HTTP应用程序会根据方法的不同做出不同的事情，比如，代理可能会将POST请求直接发送给服务器，而将GET请求发送给另一个HTTP应用程序（比如web缓存）。TRACE并不提供区分这些方法的机制。通常，中间应用程序会自行决定对TRACE请求的处理方式。

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

7. OPTIONS

        OPTIONS方法请求web服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。（有些服务器可能只支持对一些特殊类型的对象使用特定的操作）。

        这为客户端应用程序提供了一种手段，使其不用实际访问哪些资源就能判定访问各种资源的最优方式。

图8 OPTIONS示例

8. DELETE

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

图9 DELETE示例

9. 扩展方法

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

四、状态码

1. 1XX——信息性状态码

• 100（Continue）：说明收到了请求的初始部分，请客户端继续。发送了这个状态码之后，服务器在收到请求之后必须进行响应。

• 101（Switching Protocols）：说明服务器正在根据客户端的指定，将协议切换成Update首部所列的协议。
  

2. 2XX——成功状态码

• 200（OK）：请求没有问题，实体的主体部分包含了 所请求的资源。

• 201（Created）：用于创建服务器对象的请求（比如PUT）。响应的实体主体部分中应该包含各种引用了已创建的资源的URL，Location首部包含的则是最具体的引用。服务器必须在发送这个状态码之前创建好对象。

• 202（Accepted）：请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会完成这个请求；这只是意味着接受请求时，它看起来是有效的。服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计（或者包含一个指针，指向可以获取此信息的位置）。

• 203（Non-Authoritative Information）：实体首部包含的信息不实来自于源端服务器，而是来自资源的一份副本。如果中间节点上有一份资源副本，但无法或者没有对它所发送的与资源有关的元信息（首部）进行验证，就会出现这种情况。这种响应码并不是非用不可的。如果实体首部来自源端服务器，响应为200状态的应用程序就可以将其作为一种可选项使用。

• 204（No Content）：响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主要用于在浏览器不转为显示新文档的 情况下，对其进行更新（比如刷新一个表单页面）。

• 205（Reset Content）：另一个主要用于浏览的代码。负责告知浏览器清除当前页面中的所有HTML表单元素。

• 206（Partial Content）：成功执行了一个部分或Range（范围）请求。206响应中必须包含Content-Range、Date以及ETag或Content-Location首部。

3. 3XX——重定向状态码

• 300（Multiple Choices）：客户端请求一个实际指向多个资源的URL时会返回这个状态码。比如服务器上有某个HTML文档的英语和法语版本。返回这个代码时会带有一个选项列表；这样用户就可以选择它希望使用的那一项了。有多个版本可用时，客户端需要沟通解决。

• 301（Moved Permanently）：在请求的URL已被移除时使用。响应的Location首部中应该包含资源现状所处的URL。

• 302（Found）：与301状态码类似，但是，客户端应该使用Location首部给出给出的URL来临时定位资源。将来的请求仍应使用老的URL。用于HTTP/1.0。

• 303（See Other）：告知客户端应该用另一个URL来获取资源。新的URL位于响应报文的Location首部，其主要目的是允许POST请求的响应将客户端定向到某个资源上去。

• 304（Not Modified）：客户端可以通过所包含的请求首部，使其请求变成有条件的。如果客户端发起了一个条件GET请求，而最近资源未被修改的话，就可以用这个状态码来说明资源未被修改。带有这个状态码的响应不应该包含实体的主体部分。

• 305（User Proxy）：用来说明必须通过一个代理来访问资源。代理的位置由Location首部给出。很重要的一点是，客户端是相对某个特定资源来解析这条响应的，不能假定所有请求，甚至所有对持有所请求资源的服务器的请求都通过这个代理进行。如果客户端错误地让代理接入了某条请求，可能会引发破坏性的行为，而且会造成安全漏洞。

• 306：这个状态码不再被使用。

• 307（Temporary Redirect）：与301状态码类似，但客户端应该使用Location首部给出的URL来临时定位资源。将来的请求应该使用老的URL。用于HTTP/1.1。

4. 4XX——客户端错误状态码

• 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 Required）：与401状态码类似，但用于要求对资源进行认证的代理服务器。

• 408（Request Timeout）：如果客户端完成请求所花的时间太长，服务器可以回送此状态码，并关闭连接。超时时长随服务器的不同有所不同，但通常对所有的合法请求来说，都是够长的。

• 409（Conflict）：用于说明请求可能在资源上引发的一些冲突。服务器丹霞请求会引发冲突时，可以发送此状态码，响应中包含描述冲突的主体。

• 410（Gone）：与404类似，只是服务器曾经拥有过此资源。主要用于web站点的维护，这样服务器的管理者就可以在资源被移除的情况下通知客户端了。

• 411（Length Required）：服务器要求在请求报文中包含Content-Length首部时使用。

• 412（Precondition Failed）：客户端发起了条件请求，且其中一个条件失败了的时候使用。客户端包含了Expect首部时发起的就是条件请求。

• 413（Request Entity Too Large）：客户端发送的实体主体部分比服务器能够活着希望处理的要大时，使用此状态码。

• 414（Request URI Too Long）：客户端所发请求中的请求URL比服务器能够活着希望处理的要长时，使用此状态码。

• 415（Unsupported Media Type）：服务器无法理解或无法支持客户端所发实体的内容类型时，使用此状态码。

• 416（Requested Range Not Statisfiable）：请求报文所请求的是指定资源的某个范围，而此范围无效或无法满足时，使用此状态码。

• 417（Expectation Failed）：请求的Expect请求首部包含了一个期望，但服务器无法满足此期望时，使用此状态码。如果代理或其他中间应用程序有确切证据说明源端服务器会为某请求产生一个失败的期望，就可以发送这个响应状态码。

5. 5XX——服务器错误状态码

• 500（Internal Server Error）：服务器遇到一个妨碍它为请求提供服务的错误时，使用此状态码。

• 501（Not Implemented）：客户端发起的请求超出服务器的能力范围（比如，使用了服务器不支持的请求方法）时，使用此状态码。

• 502（Bad Gateway）：作为代理或网关使用的服务器从请求响应链的下一跳链路上收到了一条伪响应（比如，它无法连接到其父网关）时，使用此状态码。

• 503（Service Unavailable）：用来说明服务器现在无法为请求提供服务，但将来可以。如果服务器知道说明时候资源会变为可用的，可以在响应中包含一个Retry-After。

• 504（Gateway Timeout）：与状态码408类似，只是这里的响应来自一个网关或代理。

• 505（HTTP Version Not Supported）：服务器收到的请求使用了它无法或不愿支持的协议版本时，使用此状态码。

五、首部

1. 通用首部

        有些首部提供了与报文相关的最基本的信息。它们被称为通用首部。通用的信息首部如下：

• Connection：允许客户端和服务器指定与请求/响应连接有关的选项

• Date：提供日期和时间标志，说明报文是什么时候创建的。

• MIME-Version：给出了发送端使用的MIME版本。

• Trailer：如果报文采用了分块传输编码方式，就可以用这个首部列出位于报文拖鞋（trailer）部分的首部集合。

• Update：给出了发送端可能想要“升级”使用的新版本或协议。

• Via：显示了报文经过的中间节点（代理、网关）。

        HTTP/1.0引入了第一个允许HTTP应用程序缓存对象本地副本的首部，这样就不需要总是直接从源端服务器获取了。最新的HTTP版本有非常丰富的缓存参数集。下面是基本的缓存首部。

• Cache-Control：用于随报文传送缓存指示。

• Pragma：另一种随报文传送指示的方式，但并不专用于缓存。
  

2. 更多

        具体参考《http权威指南》。