标签：
报文的组成部分
? ?
报文由三个部分组成：对报文进行描述的起始行（start line）、包含属性的首部（header）块，以及可选的、包含数据的主体（body）部分。
? ?
所有的 HTTP 报文都以一个起始行作为开始。请求报文的起始行也就是请求行说明了要做些什么。响应报文的起始行也就是响应行说明发生了什么。
? ?
请求行包含了一个方法和一个请求 URL，这个方法描述了服务器应该执行的操作，请求 URL 描述了要对哪个资源执行这个方法。请求行中还包含 HTTP 的版本，用来告知服务器，客户端使用的是哪种 HTTP。
所有这些字段都由空格符分隔。下图中，请求方法为 GET，请求 URL 为/test/hi-there.txt，版本为 HTTP/1.1
? ?
响应行包含了响应报文使用的 HTTP 版本、数字状态码，以及描述操作状态的文本形式的原因短语。
所有这些字段都由空格符进行分隔。上图中，HTTP 版本为 HTTP/1.0，状态码为 200（表示成功），原因短语为 OK，表示文档已经被成功返回了。
? ?
报文的分类
? ?
所有的 HTTP 报文都可以分为两类：请求报文和响应报文
? ?
这是请求报文的格式：
<method> <request-URL> <version>
<headers>
? ?
<entity-body>
? ?
这是响应报文的格式（注意，只有起始行的语法有所不同）：
<version> <status> <reason-phrase>
<headers>
? ?
<entity-body>
? ?
报文各部分的描述
? ?
下面是对各部分的简要描述。
?
方法（method）
? ?
客户端希望服务器对资源执行的动作。是一个单独的词，比如，GET 方法负责从服务器获取一个文档，POST 方法会向服务器发送需要处理的数据。
? ?
请求 URL（request-URL）
? ?
命名了所请求资源，或者 URL 路径组件的完整 URL。
? ?
版本（version）
? ?
报文所使用的 HTTP 版本，其格式看起来是这样的：
? ?
HTTP/<major>.<minor>
? ?
其中主要版本号（major）和次要版本号（minor）都是整数。本章稍后会详细说明 HTTP 的版本问题。
? ?
状态码（status-code）
? ?
这三位数字描述了请求过程
? ?
状态码分类
? ?
?整体范围? | ?已定义范围? | ?分 类? |
?100～199? | ?100～101? | ?信息提示? |
?200～299? | ?200～206? | ?成功? |
?300～399? | ?300～305? | ?重定向? |
?400～499? | ?400～415? | ?客户端错误? |
?500～599? | ?500～505? | ?服务器错误? |
? ?
附录中有状态码的具体含义分类，这里限于篇幅就不在此赘述，有兴趣的可以下拉到最后查看
? ?
常见状态码
? ?
?状 态 码? | ?原因短语? | ?含 义? |
?200? | ?OK? | ?成功。请求的所有数据都在响应主体中? |
?401? | ?Unauthorized（未授权）? | ?需要输入用户名和密码? |
?404? | ?Not Found（未找到）? | ?服务器无法找到所请求URL对应的资源? |
? ?
首部（header）
? ?
HTTP 首部字段向请求和响应报文中添加了一些附加信息。本质上来说，它们只是一些名 / 值对的列表。比如，下面的首部行会向 Content-Length 首部字段赋值 19：
Content-length：19
? ?
?首部实例? | ?描 述? |
?Date:Tue,3Oct 1997 02:16:03 GMT? | ?服务器产生响应的日期? |
?Content-length:15040? | ?实体的主体部分包含了15 040字节的数据? |
?Content-type:image/gif? | ?实体的主体部分是一个GIF图片? |
?Accept: image/gif, image/jpeg, text/html? | ?客户端可以接收GIF图片和JPEG图片以及HTML? |
? ?
报文中方法分类
? ?
GET
? ?
GET 是最常用的方法。通常用于请求服务器发送某个资源。
? ?
HEAD
? ?
HEAD 方法与 GET 方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。使用 HEAD，可以：
?
在不获取资源的情况下了解资源的情况（比如，判断其类型）；
通过查看响应中的状态码，看看某个对象是否存在；
通过查看首部，测试资源是否被修改了。
? ?
HEAD 示例
? ?
PUT
? ?
与 GET 从服务器读取文档相反，PUT 方法会向服务器写入文档。有些发布系统允许用户创建 Web 页面，并用 PUT 直接将其安装到 Web 服务器上去。
? ?
PUT 示例
? ?
? ?
PUT 方法的语义就是让服务器用请求的主体部分来创建一个由所请求的 URL 命名的新文档，或者，如果那个 URL 已经存在的话，就用这个主体来替代它。
? ?
因为 PUT 允许用户对内容进行修改，所以很多 Web 服务器都要求在执行 PUT 之前，用密码登录。
? ?
POST
? ?
POST 方法起初是用来向服务器输入数据的。实际上，通常会用它来支持 HTML 的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方（比如，送到一个服务器网关程序中，然后由这个程序对其进行处理）。图 3-10 显示了一个用 POST 方法发起 HTTP 请求——向服务器发送表单数据——的客户端。
POST 用于向服务器发送数据。PUT 用于向服务器上的资源（例如文件）中存储数据。
? ?
OPTIONS
? ?
OPTIONS 方法请求 Web 服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。（有些服务器可能只支持对一些特殊类型的对象使用特定的操作）。
这为客户端应用程序提供了一种手段，使其不用实际访问那些资源就能判定访问各种资源的最优方式。图 3-12 显示了一个使用 OPTIONS 方法的请求。
? ?
DELETE
? ?
顾名思义，DELETE 方法所做的事情就是请服务器删除请求 URL 所指定的资源。但是，客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求。图 3-13 显示了一个 DELETE 方法实例。
? ?
? ?
附录
? ?
表3-6 信息性状态码及原因短语
?状态码? | ?原因短语? | ?含 义? |
?100? | ?Continue? | ?说明收到了请求的初始部分，请客户端继续。发送了这个状态码之后，服务器在收到请求之后必须进行响应。更多信息请参见附录C中的Expect?首部介绍 |
?101? | ?Switching Protocols? | ?说明服务器正在根据客户端的指定，将协议切换成Update?首部所列的 |
表3-7 成功状态码和原因短语
? ?
?状态码? | ?原因短语? | ?含 义? |
?200? | ?OK? | ?请求没问题，实体的主体部分包含了所请求的资源? |
?201? | ?Created? | ?用于创建服务器对象的请求（比如，PUT）。响应的实体主体部分中应该包含各种引用了已创建的资源的URL，Location首部包含的则是最具体的引用。更多有关Location首部的信息参见表3-21。 ?服务器必须在发送这个状态码之前创建好对象 |
?202? | ?Accepted? | ?请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会完成这个请求；这只是意味着接受请求时，它看起来是有效的。 ?服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计（或者包含一个指针，指向可以获取此信息的位置） |
?203? | ?Non-Authoritative Information? | ?实体首部（更多有关实体首部的信息参见3.5.4节）包含的信息不是来自于源端服务器，而是来自资源的一份副本。如果中间节点上有一份资源副本，但无法或者没有对它所发送的与资源有关的元信息（首部）进行验证，就会出现这种情况。 ?这种响应码并不是非用不可的；如果实体首部来自源端服务器，响应为200状态的应用程序就可以将其作为一种可选项使用 |
?204? | ?No Content? | ?响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主要用于在浏览器不转为显示新文档的情况下，对其进行更新（比如刷新一个表单页面）? |
?205? | ?Reset Content? | ?另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所有HTML 表单元素? |
?206? | ?Partial Content? | ?成功执行了一个部分或Range（范围）请求。稍后我们会看到，客户端可以通过一些特殊的首部来获取部分或某个范围内的文档——这个状态码就说明范围请求成功了。更多有关Range首部的内容参见15.9节。 206响应中必须包含Content-Range、Date以及ETag或Content-Location?首部 |
? ?
表3-8 重定向状态码与原因短语
? ?
?状态码? | ?原因短语? | ?含 义? |
?300? | ?Multiple Choices? | ?客户端请求一个实际指向多个资源的URL时会返回这个状态码，比如服务器上有某个HTML文档的英语和法语版本。返回这个代码时会带有一个选项列表；这样用户就可以选择他希望使用的那一项了。有多个版本可用时，客户端需要沟通解决，更多与此有关的信息请参见第17章。服务器可以在Location?首部包含首选URL |
?301? | ?Moved Permanently? | ?在请求的URL已被移除时使用。响应的Location?首部中应该包含资源现在所处的URL |
?302? | ?Found? | ?与301状态码类似；但是，客户端应该使用Location?首部给出的URL来临时定位资源。将来的请求仍应使用老的URL |
?303? | ?See Other? | ?告知客户端应该用另一个URL来获取资源。新的URL位于响应报文的?Location??首部。其主要目的是允许POST请求的响应将客户端定向到某个资源上去 |
?304? | ?Not Modified? | ?客户端可以通过所包含的请求首部，使其请求变成有条件的。更多有关条件首部的内容请参见第3章。如果客户端发起了一个条件GET请求，而最近资源未被修改的话，就可以用这个状态码来说明资源未被修改。带有这个状态码的响应不应该包含实体的主体部分? |
?305? | ?Use Proxy? | ?用来说明必须通过一个代理来访问资源；代理的位置由Location?首部给出。很重要的一点是，客户端是相对某个特定资源来解析这条响应的，不能假定所有请求，甚至所有对持有所请求资源的服务器的请求都通过这个代理进行。如果客户端错误地让代理介入了某条请求，可能会引发破坏性的行为，而且会造成安全漏洞 |
?306? | ?（未使用）? | ?当前未使用? |
?307? | ?Temporary Redirect? | ?与301状态码类似；但客户端应该使用Location?首部给出的URL来临时定位资源。将来的请求应 |
? ?
表3-9 客户端错误状态码及原因短语
? ?
?状态码? | ?原因短语? | ?含 义? |
?400? | ?Bad Request? | ?用于告知客户端它发送了一个错误的请求? |
?401? | ?Unauthorized? | ?与适当的首部一同返回，在这些首部中请求客户端在获取对资源的访问权之前，对自己进行认证。更多有关认证的内容请参见 12.1节? |
?402? | ?Payment Required? | ?现在这个状态码还未使用，但已经被保留，以作未来之用? |
?403? | ?Forbidden? | ?用于说明请求被服务器拒绝了。如果服务器想说明为什么拒绝请求，可以包含实体的主体部分来对原因进行描述。但这个状态码通常是在服务器不想说明拒绝原因的时候使用的? |
?404? | ?Not Found? | ?用于说明服务器无法找到所请求的URL。通常会包含一个实体，以便客户端应用程序显示给用户看? |
?405? | ?Method Not Allowed? | ?发起的请求中带有所请求的URL不支持的方法时，使用此状态码。应该在响应中包含Allow首部，以告知客户端对所请求的资源可以使用哪些方法。更多有关Allow?首部的信息请参见3.5.4节 |
?406? | ?Not Acceptable? | ?客户端可以指定参数来说明它们愿意接收什么类型的实体。服务器没有与客户端可接受的URL相匹配的资源时，使用此代码。通常，服务器会包含一些首部，以便客户端弄清楚为什么请求无法满足。更多信息请参见第17章? |
?407? | ?Proxy Authentication Required? | ?与401状态码类似，但用于要求对资源进行认证的代理服务器? |
?408? | ?Request Timeout? | ?如果客户端完成请求所花的时间太长，服务器可以回送此状态码，并关闭连接。超时时长随服务器的不同有所不同，但通常对所有的合法请求来说，都是够长的? |
?409? | ?Conflict? | ?用于说明请求可能在资源上引发的一些冲突。服务器担心请求会引发冲突时，可以发送此状态码。响应中应该包含描述冲突的主体? |
?410? | ?Gone? | ?与404类似，只是服务器曾经拥有过此资源。主要用于Web站点的维护，这样服务器的管理者就可以在资源被移除的情况下通知客户端了? |
?411? | ?Length Required? | ?服务器要求在请求报文中包含Content-Length首部时使用。更多有关Content-Length?首部的信息请参见3.5.4节 |
?412? | ?Precondition Failed? | ?客户端发起了条件请求，且其中一个条件失败了的时候使用。客户端包含了Expect首部时发起的就是条件请求。更多有关Expect首部的内容请参见附录C中Expect?部分 |
?413? | ?Request Entity Too Large? | ?客户端发送的实体主体部分比服务器能够或者希望处理的要大时，使用此状态码? |
?414? | ?Request URI Too Long? | ?客户端所发请求中的请求URL比服务器能够或者希望处理的要长时，使用此状态码? |
?415? | ?Unsupported Media Type? | ?服务器无法理解或无法支持客户端所发实体的内容类型时，使用此状态 |
? ?
表3-10 服务器错误状态码及原因短语
? ?
?状态码? | ?原因短语? | ?含 义? |
?500? | ?Internal Server Error? | ?服务器遇到一个妨碍它为请求提供服务的错误时，使用此状态码? |
?501? | ?Not Implemented? | ?客户端发起的请求超出服务器的能力范围（比如，使用了服务器不支持的请求方法）时，使用此状态码? |
?502? | ?Bad Gateway? | ?作为代理或网关使用的服务器从请求响应链的下一条链路上收到了一条伪响应（比如，它无法连接到其父网关）时，使用此状态码? |
?503? | ?Service Unavailable? | ?用来说明服务器现在无法为请求提供服务，但将来可以。如果服务器知道什么时候资源会变为可用的，可以在响应中包含一个Retry-After首部。更多有关Retry-After?首部的信息请参见3.5.3节 |
?504? | ?Gateway Timeout? | ?与状态码408类似，只是这里的响应来自一个网关或代理，它们在等待另一服务器对其请求进行响应时超时了? |
?505? | ?HTTP Version Not Supported? | ?服务器收到的请求使用了它无法或不愿支持的协议版本时，使用此状态码。有些服务器应用程序会选择不支持协议的早期版 |
? ?
标签：
原文地址：http://www.cnblogs.com/keedor/p/4530954.html
