记录 ---- HTTP报文

时间 2020-07-06

标签记录 http 报文栏目 HTTP/TCP 繁體版

原文原文链接

HTTP报文

报文是如何流动的

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

HTTP使用术语流入(inbound)和流出(outbound)来描述事务处理(transaction)的方向。报文流入源端服务器，工做完成以后，会流回用户的Agent代理中。无论是请求报文仍是响应报文，全部报文都会向下游(downstream)流动。全部报文的发送者都在接收者的上游(upstream)。
浏览器

HTTP报文的语法和组成部分

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

起始行和首部就是由行分隔的ASCII文本。每行都以一个由两个字符组成的行终止序列做为结束，其中包括一个回车符和一个换行符。这个行终止序列能够写作CRLF。须要指出的是，尽管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 版本，其中主要版本号(major)和次要版本号(minor)都是整数。
状态码(status-code)：这三位数字描述了请求过程当中所发生的状况。每一个状态码的第一位数字都用于描述状态的通常类别("成功"、"出错"等)。
缘由短语(reason-phrase)：数字状态码的可读版本，包含行终止序列以前的全部文本。缘由短语只对人类有意义，所以，好比说，尽管响应行"HTTP/1.0 200 NOT OK"和"HTTP/1.0 200 OK"中缘由短语的含义不一样，但一样都会被看成成功指示处理。
首部(header)：能够有零个或多个首部，每一个首部都包含一个名字，后面跟着一个冒号(:)，而后是一个可选的空格，接着是一个值，最后是一个CRLF。首部是由一个空行(CRLF)结束的，表示了首部列表的结束和实体主体部分的开始。有些 HTTP 版本，好比HTTP/1.1，要求有效的请求或响应报文中必须包含特定的首部。
实体的主体部分(entity-body)：实体的主体部分包含一个由任意数据组成的数据块。并非全部的报文都包含实体的主体部分，有时，报文只是以一个CRLF结束。

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

起始行

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

请求行：请求报文请求服务器对资源进行一些操做。请求报文的起始行，或称为请求行，包含了一个方法和一个请求URL，这个方法描述了服务器应该执行的操做，请求URL描述了要对哪一个资源执行这个方法。请求行中还包含 HTTP 的版本，用来告知服务器，客户端使用的是哪一种HTTP。全部这些字段都由空格符分隔。在 HTTP/1.0 以前，并不要求请求行中包含 HTTP 版本号。
响应行：响应报文承载了状态信息和操做产生的全部结果数据，将其返回给客户端。响应报文的起始行，或称为响应行，包含了响应报文使用的HTTP版本、数字状态码，以及描述操做状态的文本形式的缘由短语。全部这些字段都由空格符进行分隔。在 HTTP/1.0 以前，并不要求在响应中包含响应行。
方法：请求的起始行以方法做为开始，方法用来告知服务器要作些什么。HTTP规范中定义了一组经常使用的请求方法。好比，GET方法负责从服务器获取一个文档，POST方法会向服务器发送须要处理的数据，OPTIONS方法用于肯定Web服务器的通常功能，或者Web服务器处理特定资源的能力。注意，有些方法的请求报文中有主体，有些则是无主体的请求。并非全部服务器都实现了全部的7种方法。并且，因为HTTP设计得易于扩展，因此除了这些方法以外，其余服务器可能还会实现一些本身的请求方法。这些附加的方法是对 HTTP 规范的扩展，所以被称为扩展方法。
状态码：方法是用来告诉服务器作什么事情的，状态码则用来告诉客户端，发生了什么事情。状态码位于响应的起始行中。客户端向一个HTTP服务器发送请求报文时，会发生不少事情。幸运的话，请求会成功完成。但你不会老是那么幸运的。服务器可能会告诉你没法找到所请求的资源，你没有访问资源的权限，或者资源被移到了其余地方。状态码是在每条响应报文的起始行中返回的。会返回一个数字状态和一个可读的状态。数字码便于程序进行差错处理，而缘由短语则更便于人们理解。能够经过三位数字代码对不一样状态码进行分类。200到299之间的状态码表示成功。300到399之间的代码表示资源已经被移走了。400到499之间的代码表示客户端的请求出错了。500到599之间的代码表示服务器出错了。当前的HTTP版本只为每类状态定义了几个代码。随着协议的发展，HTTP规范中会正式地定义更多的状态码。若是收到了不认识的状态码，多是有人将其做为当前协议的扩展定义的。能够根据其所处范围，将它做为那个类别中一个普通的成员来处理。
缘由短语：缘由短语是响应起始行中的最后一个组件。它为状态码提供了文本形式的解释。缘由短语和状态码是成对出现的。缘由短语是状态码的可读版本，应用程序开发者将其传送给用户，用以说明在请求期间发生了什么状况。HTTP规范并无提供任何硬性规定，要求缘由短语以何种形式出现。
版本号：版本号会以"HTTP/x.y"的形式出如今请求和响应报文的起始行中。为HTTP应用程序提供了一种将本身所遵循的协议版本告知对方的方式。使用版本号的目的是为使用HTTP的应用程序提供一种线索，以便互相了解对方的能力和报文格式。在与使用"HTTP 1.1"的应用程序进行通讯的"HTTP 1.2"应用程序应该知道，它不能使用任何新的1.2特性，由于使用老版本协议的应用程序极可能没法实现这些特性。版本号说明了应用程序支持的最高HTTP版本。但"HTTP/1.0"应用程序在解释包含"HTTP/1.1"的响应时，会认为这个响应是个1.1响应，而实际上这只是响应应用程序所使用的协议等级，在这些状况下，版本号会在应用程序之间形成误解。

首部

跟在起始行后面的就是零个、一个或多个HTTP首部字段。HTTP首部字段向请求和响应报文中添加了一些附加信息。本质上来讲，它们只是一些键/值对的列表。
测试

首部分类：HTTP规范定义了几种首部字段。应用程序也能够随意发明本身所用的首部。每一个HTTP首部都有一种简单的语法：名字后面跟着冒号(:)，而后跟上可选的空格，再跟上字段值，最后是一个CRLF。HTTP 首部能够分为如下几类。
优化

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

首部延续行：将长的首部行分为多行能够提升可读性，多出来的每行前面至少要有一个空格或制表符(tab)。
ui

实体的主体部分

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

请求报文支持的各类功能(方法)

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

注意：并非每一个服务器都实现了全部的方法。若是一台服务器要与"HTTP 1.1"兼容，那么只要为其资源实现GET方法和HEAD方法就能够了。即便服务器实现了全部这些方法，这些方法的使用极可能也是受限的。例如，支持 DELETE 方法或 PUT 方法的服务器可能并不但愿任何人都可以删除或存储资源。这些限制一般都是在服务器的配置中进行设置的，所以会随着站点和服务器的不一样而有所不一样。

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

GET：GET是最经常使用的方法。一般用于请求服务器发送某个资源。
HEAD：HEAD方法与GET方法的行为很相似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就容许客户端在未获取实际资源的状况下，对资源的首部进行检查。服务器开发者必须确保返回的首部与GET请求所返回的首部彻底相同。使用HEAD，能够：
- 在不获取资源的状况下了解资源的状况（好比，判断其类型）；
- 经过查看响应中的状态码，看看某个对象是否存在；
- 经过查看首部，测试资源是否被修改了。
PUT：与GET从服务器读取文档相反，PUT方法会向服务器写入文档。有些发布系统容许用户建立Web页面，并用PUT直接将其安装到Web服务器上去。PUT方法的语义就是让服务器用请求的主体部分来建立一个由所请求的URL命名的新文档，或者，若是那个URL已经存在的话，就用这个主体来替代它。由于PUT容许用户对内容进行修改，因此不少Web服务器都要求在执行PUT以前，用密码登陆。
POST：POST方法起初是用来向服务器输入数据的。实际上，一般会用它来支持HTML的表单。表单中填好的数据一般会被送给服务器，而后由服务器将其发送到它要去的地方(好比，送到一个服务器网关程序中，而后由这个程序对其进行处理)。
TRACE：客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其余一些应用程序。每一个中间节点均可能会修改原始的HTTP请求。TRACE方法容许客户端在最终将请求发送给服务器时，看看它变成了什么样子。TRACE请求会在目的服务器端发起一个"环回"诊断。行程最后一站的服务器会弹回一条TRACE响应，并在响应主体中携带它收到的原始请求报文。这样客户端就能够查看在全部中间HTTP应用程序组成的请求/响应链上，原始报文是否，以及如何被毁坏或修改过。TRACE方法主要用于诊断；也就是说，用于验证请求是否如愿穿过了请求/响应链。它也是一种很好的工具，能够用来查看代理和其余应用程序对用户请求所产生效果。尽管TRACE能够很方便地用于诊断，但它确实也有缺点，它假定中间应用程序对各类不一样类型请求(不一样的方法——GET、HEAD、POST等)的处理是相同的。不少HTTP应用程序会根据方法的不一样作出不一样的事情——好比，代理可能会将POST请求直接发送给服务器，而将GET请求发送给另外一个HTTP应用程序(好比Web缓存)。TRACE并不提供区分这些方法的机制。一般，中间应用程序会自行决定对TRACE请求的处理方式。TRACE请求中不能带有实体的主体部分。TRACE响应的实体主体部分包含了响应服务器收到的请求的精确副本。
OPTIONS：OPTIONS方法请求Web服务器告知其支持的各类功能。能够询问服务器一般支持哪些方法，或者对某些特殊资源支持哪些方法。(有些服务器可能只支持对一些特殊类型的对象使用特定的操做)。这为客户端应用程序提供了一种手段，使其不用实际访问那些资源就能断定访问各类资源的最优方式。
DELETE：顾名思义，DELETE方法所作的事情就是请服务器删除请求URL所指定的资源。可是，客户端应用程序没法保证删除操做必定会被执行。由于HTTP规范容许服务器在不通知客户端的状况下撤销请求。

扩展方法：HTTP被设计成字段可扩展的，这样新的特性就不会使老的软件失效了。扩展方法指的就是没有在"HTTP/1.1"规范中定义的方法。服务器会为它所管理的资源实现一些HTTP服务，这些方法为开发者提供了一种扩展这些HTTP服务能力的手段。并非全部的扩展方法都是在正式规范中定义的，认识到这一点很重要。若是你定义了一个扩展方法，极可能大部分HTTP应用程序都没法理解。一样，你的HTTP应用程序也可能会遇到一些其余应用程序在用的，而它并不理解的扩展方法。在这些状况下，最好对扩展方法宽容一些。若是可以在不破坏端到端行为的状况下将带有未知方法的报文传递给下游服务器的话，代理应尝试传递这些报文。若是可能破坏端到端行为，则应以"501 Not Implemented(没法实现)"状态码进行响应。最好按惯例"对所发送的内容要求严一点，对所接收的内容宽容一些"来处理扩展方法(以及通常的HTTP扩展)。

和响应报文一块儿返回的各类状态码

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

HTTP状态码被分红了五大类。状态码为客户端提供了一种理解事务处理结果的便捷方式。尽管并无实际的规范对缘由短语的确切文本进行说明。

100～199 --- 信息性状态码

HTTP/1.1 向协议中引入了信息性状态码。这些状态码相对较新，关于其复杂性和感知价值存在一些争议。

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

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

客户端与"100 Continue"：若是客户端在向服务器发送一个实体，而且愿意在发送实体以前等待"100 Continue"响应，那么，客户端就要发送一个携带了值为"100 Continue"的""Expect"请求首部。若是客户端没有发送实体，就不该该发送"100 Continue Expect"首部，由于这样会使服务器误觉得客户端要发送一个实体。从不少方面来看，"100 Continue"都是一种优化。客户端应用程序只有在避免向服务器发送一个服务器没法处理或使用的大实体时，才应该使用"100 Continue"。因为起初对"100 Continue"状态存在一些困惑，所以发送了值为"100 Continue"的"Expect"首部的客户端不该该永远在那儿等待服务器发送"100 Continue"响应。超时必定时间以后，客户端应该直接将实体发送出去。实际上，客户端程序的实现者也应该作好应对非预期"100 Continue"响应的准备。有些出错的 HTTP 应用程序会不合时宜地发送这个状态码。
服务器与"100 Continue"：若是服务器收到了一条带有值为"100 Continue"的"Expect"首部的请求，它会用"100 Continue"响应或一条错误码来进行响应。服务器永远也不该该向没有发送"100 Continue"指望的客户端发送"100 Continue"状态码。但如前所述，有些出错的服务器可能会这么作。若是出于某种缘由，服务器在有机会发送"100 Continue"响应以前就收到了部分(或所有)的实体，就说明客户端已经决定继续发送数据了，这样，服务器就不须要发送这个状态码了。但服务器读完请求以后，仍是应该为请求发送一个最终状态码(它能够跳过"100 Continue"状态)。最后，若是服务器收到了带有"100 Continue"指望的请求，并且它决定在读取实体的主体部分以前(好比，由于出错而)结束请求，就不该该仅仅是发送一条响应并关闭链接，由于这样会妨碍客户端接收响应。
代理与"100 Continue"：若是代理从客户端收到了一条带有"100 Continue"指望的请求，它须要作几件事情。若是代理知道下一跳服务器是"HTTP/1.1"兼容的，或者并不知道下一跳服务器与哪一个版本兼容，它都应该将"Expect"首部放在请求中向下转发。若是它知道下一跳服务器只能与"HTTP/1.1"以前的版本兼容，就应该以"417 Expectation Failed"错误进行响应。若是代理决定表明与"HTTP/1.0"或以前版本兼容的客户端，在其请求中放入"Expect"首部和"100 Continue"值，那么，(若是它从服务器收到了"100 Continue"响应)它就不该该将"100 Continue"响应转发给客户端，由于客户端可能不知道该拿它怎么办。代理维护一些有关下一跳服务器及其所支持的HTTP版本的状态信息(至少要维护那些最近收到过请求的服务器的相关状态)是有好处的，这样它们就能够更好地处理收到的那些带有"100 Continue"指望的请求了。

200～299 --- 成功状态码

客户端发起请求时，这些请求一般都是成功的。服务器有一组用来表示成功的状态码，分别对应于不一样类型的请求。

状态码	缘由短语	含义
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首部。

300～399 --- 重定向状态码

重定向状态码要么告知客户端使用替代位置来访问他们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容。若是资源已被移动，可发送一个重定向状态码和一个可选的Location首部来告知客户端资源已被移走，以及如今能够在哪里找到它。这样，浏览器就能够在不打扰使用者的状况下，透明地转入新的位置了。能够经过某些重定向状态码对资源的应用程序本地副本与源端服务器上的资源进行验证。好比，HTTP 应用程序能够查看其资源的本地副本是否仍然是最新的，或者在源端服务器上资源是否被修改过。总之，在对那些包含了重定向状态码的非 HEAD 请求进行响应时，最好要包含一个实体，并在实体中包含描述信息和指向(多个)重定向URL的连接。

状态码	缘由短语	含义
300	Multiple Choices	客户端请求一个实际指向多个资源的URL时会返回这个状态码，好比服务器上有某个HTML文档的英语和法语版本。返回这个代码时会带有一个选项列表；这样用户就能够选择他但愿使用的那一项了。有多个版本可用时，客户端须要沟通解决。服务器能够在Location首部包含首选URL。
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首部给出。很重要的一点是，客户端是相对某个特定资源来解析这条响应的，不能假定全部请求，甚至全部对持有所请求资源的服务器的请求都经过这个代理进行。若是客户端错误地让代理介入了某条请求，可能会引起破坏性的行为，并且会形成安全漏洞。
307	Temporary Redirect	与301状态码相似；但客户端应该使用Location首部给出的URL来临时定位资源。未来的请求应该使用老的URL。

30二、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 --- 客户端错误状态码

有时客户端会发送一些服务器没法处理的东西，好比格式错误的请求报文，或者最多见的是，请求一个不存在的URL。浏览网页时，咱们都看到过臭名昭著的"404 Not Found"错误码——这只是服务器在告诉咱们，它对咱们请求的资源一无所知。不少客户端错误都是由浏览器来处理的，甚至不会打扰到你。只有少许错误，好比 404，仍是会穿过浏览器来到用户面前。

状态码	缘由短语	含义
400	Bad Request	用于告知客户端它发送了一个错误的请求。
401	Unauthorized	与适当的首部一同返回，在这些首部中请求客户端在获取对资源的访问权以前，对本身进行认证。
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 Satisfiable	请求报文所请求的是指定资源的某个范围，而此范围无效或没法知足时，使用此状态码
417	Expectation Failed	请求的Expect请求首部包含了一个指望，但服务器没法知足此指望时，使用此状态码。若是代理或其余中间应用程序有确切证听说明源端服务器会为某请求产生一个失败的指望，就能够发送这个响应状态码。

500～599 --- 服务器错误状态码

有时客户端发送了一条有效请求，服务器自身却出错了。这多是客户端碰上了服务器的缺陷，或者服务器上的子元素，好比某个网关资源，出了错。代理尝试着表明客户端与服务器进行交流时，常常会出现问题。代理会发布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	服务器收到的请求使用了它没法或不肯支持的协议版本时，使用此状态码。有些服务器应用程序会选择不支持协议的早期版本。

各类各样的HTTP首部都是用来作什么的

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

通用首部：这些是客户端和服务器均可以使用的通用首部。能够在客户端、服务器和其余应用程序之间提供一些很是有用的通用功能。
请求首部：请求首部是请求报文特有的。它们为服务器提供了一些额外信息，好比客户端但愿接收什么类型的数据。
响应首部：响应报文有本身的首部集，以便为客户端提供信息(好比，客户端在与哪一种类型的服务器进行交互)。
实体首部：实体首部指的是用于应对实体主体部分的首部。好比，能够用实体首部来讲明实体主体部分的数据类型。
扩展首部：扩展首部是非标准的首部，由应用程序开发者建立，但还未添加到已批准的 HTTP 规范中去。即便不知道这些扩展首部的含义，HTTP 程序也要接受它们并对其进行转发。

通用首部

有些首部提供了与报文相关的最基本的信息，它们被称为通用首部。不论报文是何类型，都为其提供一些有用信息。

通用的信息性首部

首部	描述
Connection	容许客户端和服务器指定与请求/响应链接有关的选项
Date	提供日期和时间标志，说明报文是什么时间建立的
MIME-Version	给出了发送端使用的MIME版本
Trailer	若是报文采用了分块传输编码(chunked transfer encoding)方式，就能够用这个首部列出位于报文拖挂(trailer)部分的首部集合
Transfer-Encoding	告知接收端为了保证报文的可靠传输，对报文采用了什么编码方式
Update	给出了发送端可能想要"升级"使用的新版本或协议
Via	显示了报文通过的中间节点(代理、网关)

通用缓存首部："HTTP/1.0"引入了第一个容许HTTP应用程序缓存对象本地副本的首部，这样就不须要老是直接从源端服务器获取了。最新的HTTP版本有很是丰富的缓存参数集。

首部	描述
Cache-Control	用于随报文传送缓存指示
Pragma	另外一种随报文传送指示的方式，但并不专用于缓存

请求首部

请求首部是只在请求报文中有意义的首部。用于说明是谁或什么在发送请求、请求源自何处，或者客户端的喜爱及能力。服务器能够根据请求首部给出的客户端信息，试着为客户端提供更好的响应。

请求的信息性首部

首部	描述
Client-IP	提供了运行客户端的机器的IP地址
From	提供了客户端用户的E-mail地址
Host	给出了接收请求的服务器的主机名和端口号
Referer	提供了包含当前请求URI的文档的URL
UA-Color	提供了与客户端显示器的显示颜色有关的信息
UA-CPU6	给出了客户端CPU的类型或制造商
UA-Disp	提供了与客户端显示器(屏幕)能力有关的信息
UA-OS	给出了运行在客户端机器上的操做系统名称及版本
UA-Pixels	提供了客户端显示器的像素信息
User-Agent	将发起请求的应用程序名称告知服务器

Accept首部：Accept首部为客户端提供了一种将其喜爱和能力告知服务器的方式，包括它们想要什么，可使用什么，以及最重要的，它们不想要什么。这样，服务器就能够根据这些额外信息，对要发送的内容作出更明智的决定。Accept 首部会使链接的两端都受益。客户端会获得它们想要的内容，服务器则不会浪费其时间和带宽来发送客户端没法使用的东西。

首部	描述
Accept	告诉服务器可以发送哪些媒体类型
Accept-Charset	告诉服务器可以发送哪些字符集
Accept-Encoding	告诉服务器可以发送哪些编码方式
Accept-Language	告诉服务器可以发送哪些语言
TE	告诉服务器可使用哪些扩展传输编码

条件请求首部：有时客户端但愿为请求加上某些限制。好比，若是客户端已经有了一份文档副本，就但愿只在服务器上的文档与客户端拥有的副本有所区别时，才请求服务器传输文档。经过条件请求首部，客户端就能够为请求加上这种限制，要求服务器在对请求进行响应以前，确保某个条件为真。

首部	描述
Expect	容许客户端列出某请求所要求的服务器行为
If-Match	若是实体标记与文档当前的实体标记相匹配，就获取这份文档
If-Modified-Since	除非在某个指定的日期以后资源被修改过，不然就限制这个请求
If-None-Match	若是提供的实体标记与当前文档的实体标记不相符，就获取文档
If-Range	容许对文档的某个范围进行条件请求
If-Unmodified-Since	除非在某个指定日期以后资源没有被修改过，不然就限制这个请求
Range	若是服务器支持范围请求，就请求资源的指定范围

安全请求首部：HTTP自己就支持一种简单的机制，能够对请求进行质询 / 响应认证。这种机制要求客户端在获取特定的资源以前，先对自身进行认证，这样就可使事务稍微安全一些。

首部	描述
Authorization	包含了客户端提供给服务器，以便对其自身进行认证的数据
Cookie	客户端用它向服务器传送一个令牌——它并非真正的安全首部，但确实隐含了安全功能
Cookie2	用来讲明请求端支持的cookie版本

代理请求首部：随着因特网上代理的广泛应用，人们定义了几个首部来协助其更好地工做。

首部	描述
Max-Forward	在通往源端服务器的路径上，将请求转发给其余代理或网关的最大次数——与TRACE方法一同使用
Proxy-Authorization	与Authorization首部相同，但这个首部是在与代理进行认证时使用的
Proxy-Connection	与Connection首部相同，但这个首部是在与代理创建链接时使用的

响应首部

<p>响应报文有本身的响应首部集。响应首部为客户端提供了一些额外信息，好比谁在发送响应、响应者的功能，甚至与响应相关的一些特殊指令。这些首部有助于客户端处理响应，并在未来发起更好的请求。</p>

响应的信息性首部

首部	描述
Age	响应持续时间(从最初建立开始)
Public	服务器为其资源支持的请求方法列表
Retry-After	若是资源不可用的话，在此日期或时间重试
Server	服务器应用程序软件的名称和版本
Title	对HTML文档来讲，就是HTML文档的源端给出的标题
Warning	比缘由短语中更详细一些的警告报文

协商首部：若是资源有多种表示方法——好比，若是服务器上有某文档的法语和德语译稿，"HTTP/1.1"能够为服务器和客户端提供对资源进行协商的能力。

首部	描述
Accept-Ranges	对此资源来讲，服务器可接受的范围类型
Vary	服务器查看的其余首部的列表，可能会使响应发生变化；也就是说，这是一个首部列表，服务器会根据这些首部的内容挑选出最适合的资源版本发送给客户端

安全响应首部：本质上这里说的就是HTTP的质询/响应认证机制的响应侧。

首部	描述
Proxy-Authenticate	来自代理的对客户端的质询列表
Set-Cookie	不是真正的安全首部，但隐含有安全功能；能够在客户端设置一个令牌，以便服务器对客户端进行标识
Set-Cookie2	与Set-Cookie相似，""RFC 2965"Cookie定义
WWW-Authenticate	来自服务器的对客户端的质询列表

实体首部

<p>有不少首部能够用来描述HTTP报文的负荷。因为请求和响应报文中均可能包含实体部分，因此在这两种类型的报文中均可能出现这些首部。实体首部提供了有关实体及其内容的大量信息，从有关对象类型的信息，到可以对资源使用的各类有效的请求方法。总之，实体首部能够告知报文的接收者它在对什么进行处理。</p>

实体的信息性首部

首部	描述
Allow	列出了能够对此实体执行的请求方法
Location	告知客户端实体实际上位于何处；用于将接收端定向到资源的(多是新的)位置(URL)上去

内容首部：内容首部提供了与实体内容有关的特定信息，说明了其类型、尺寸以及处理它所需的其余有用信息。好比，Web 浏览器能够经过查看返回的内容类型，得知如何显示对象。

首部	描述
Content-Base	解析主体中的相对URL时使用的基础URL
Content-Encoding	对主体执行的任意编码方式
Content-Language	理解主体时最适宜使用的天然语言
Content-Length	主体的长度或尺寸
Content-Location	资源实际所处的位置
Content-MD5	主体的MD5校验和
Content-Range	在整个资源中此实体表示的字节范围
Content-Type	这个主体的对象类型

实体缓存首部：通用的缓存首部说明了如何或何时进行缓存。实体的缓存首部提供了与被缓存实体有关的信息——好比，验证已缓存的资源副本是否仍然有效所需的信息，以及更好地估计已缓存资源什么时候失效所需的线索。

首部	描述
ETag	与此实体相关的实体标记
Expires	实体再也不有效，要从原始的源端再次获取此实体的日期和时间
Last-Modified	这个实体最后一次被修改的日期和时间