HTTP 结构、状态码、首部简记

HTTP

报文

HTTP报文包括3部分：

• 起始行
• 首部字段：名字和值以:区分，每一个首部字段以\r\n换行分割。首部以一个空行表示结束。
• 主体

请求报文起始行结构：

• 方法(method): GET是这个请求的方法。
• 请求URL(request-URL): 这个request所请求的资源。
• 版本(version): 请求报文所用的HTTP版本，格式为HTTP/<major>.<minor>。

响应报文起始行结构：

• 版本(version):响应报文所用的HTTP版本，服务器应该返回相同的与请求相同的HTTP版本。
• 状态码(status-code): 这三位数描述的是请求过程的状况。
• 缘由短语(reason-phrase): 状态码的可读版本。

方法

GET

GET方法用于请求服务器发送某个资源。HTTP/1.1 要求服务器实现此方法。

HEAD

HEAD方法与GET方法相似，但服务器在响应只返回首部，不会返回实体的主体部分。这容许了客户端在未获取实际资源的状况下，对资源的首部进行检查。使用HEAD，能够：

• 再不获取资源的状况下了解资源的状况；
• 经过查看响应的状态码，检查某个对象是否存在；
• 经过查看首部，测试资源是否被修改了；

服务器开发者必须确保返回的首部与GET请求所返回的首部彻底相同。HTTTP/1.1 要求服务器实现此方法。

PUT

与GET从服务器读取文档相反，PUT方法向服务器写入文档。PUT方法的语义就是让服务器用请求的主体部分建立一个由所请求的URL命名的新文档，若是，若是那个URL已经存在，就用这个主体替换它。

POST

POST方法是用来向服务器输入数据的，一般用它来支持HTML的表单。

TRACE

TRACE请求会在目的服务器发起一个“环回”诊断。行程最后一站的服务器回弹回一条TRACE响应，并在响应的主图中携带它受到的原始请求报文。这样客户端就能够查看在全部中间HTTP应用程序组成的请求/响应链上，原始报文是否以及若是被毁坏活着修改。TRACE主要用于诊断。

缺点：TRACE假定中间应用程序对各类不一样类型的请求（GET，HEAD，POST等）的处理是相同的，可是不少HTTP应用程序会根据方法的不一样作出不一样的处理。TRACE并不提供区分这些方法的机制。

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

OPTIONS

OPTIONS方法请求Web服务器告知其支持的各类功能。

DELETE

DELETE方法请求服务器删除请求URL所指定的资源。

####其余扩展方法

扩展方法是指没有在HTTP/1.1规范中定义的方法。

常见的扩展方法

方法	描述
LOCK	容许用户“锁定”资源
MKCOL	容许用户建立资源
COPY	便于在服务器上复制资源
MOVE	在服务器上移动资源

状态码

100 ~ 199 信息状态码(HTTP/1.1中引入)

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

100 Continue的目的是对这样的状况进行优化：HTTP客户端应用程序有一个实体的主体部分要发送给服务器，但但愿在发送以前查看一下服务器是否会接受这个实体。

• 客户端与 100 Continue

若是客户端在向服务器发送一个实体，而且愿意在发送实体以前等待100 Continue响应，那么，客户端就要发送一个携带了值为100 Continue的 Expect 请求首部。若是客户端没有发送实体，就不该该发送100 Continue Expect 首部，由于这样会使服务器误觉得客户端要发送一个实体。

发送了100 Continue Expect 首部的客户端，不该该永远在等待服务器发送100 Continue响应。过期必定时间后，客户端应该直接将实体发送吹起。实际上，客户端程序也应该作好应对非预期100 Continue响应的准备。

• 服务器与 100 Continue

若是服务器收到一条带有100 Continue Expect 首部的请求，它会用100 Continue响应或者一条错误代码来进行响应。

若是服务器在有机会发送100 Continue响应以前收到了部分(或者所有)的实体，就说明客户端已经决定继续发送数据了，这样，服务器就不须要发送这个100 Continue状态码了。但服务器读完请求后，还会应该为请求发送一个最终状态码（它能够跳过100 Continue状态）。

最后，若是服务器受到了100 Continue Expect 首部的请求，且在它决定读取实体的主体部分以前结束请求，就不该该仅仅是发送一个响应并关闭链接，由于这个会妨碍客户端接受响应。

• 代理与 100 Continue

若是代理从客户端收到一个带有100 Continue Expect 首部的请求，它须要作几件事。若是代理知道下一跳服务器是HTTP/1.1兼容的，或者并不知道下一跳服务器与哪一个版本兼容，它都应该将 Expect 首部放在请求中向下转发。若是它知道下一跳服务器只能与HTTP/1.1以前的版本兼容，就应该以417 Expectation Failed错误进行响应（另外一种合理方法是，向客户端想返回100 Continue，在向服务器转发请求时，删掉 Expect 的首部）。

200 ~ 299 成功状态码

状态码	缘由短语	含义
200	OK	请求没问题，实体的主体部分包含了全部的请求资源
201	Created	用于建立服务器对象的请求(好比，PUT)。响应的实体主体部分中应该包含各类饮用了已建立的资源的URL，Location 首部包含的则是最具体的引用。 服务器必须在发送这个状态码以前建立好对象。
202	Accepted	请求已被接受，但服务器还未对其执行任何动做，不能保证服务器会完成这个请求；这只是意味着接受请求时，它看起来是有效的。 服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计（或者包含一个指针，只想能够获取此信息的位置）。
203	Non-Authoritative Infomation	实体首部包含的信息不是来自源端服务器，而是来自资源的一份副本，若是中间节点上有一份资源副本，但没法或者没有对它所发送的与资源有关的元信息(首部)进行验证，就会出现这种状况。这个状态码不是非用不可，若是实体首部来自源端服务器，响应为200状态的应用程序就能够将其做为一种可选项使用。
204	No Content	响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主要用于在浏览器不转为显示新文档的状况下，对其进行更新(好比刷新一个表单页面)。
205	Reset Content	另外一个主要用于浏览器的状态码，负责告知浏览器清楚当前页面中的全部HTML表单元素。
206	Partial Content	成功执行一个部分或 Range(范围) 请求。206响应中必须包含Content-Range、Date以及ETag或Content-Location首部。

300 ~ 399 重定向状态码

状态码	缘由短语	含义
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	Mot 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.1 中，HTTP/1.1 规范使用 303 状态码来实现一样的行为（服务器发送 303 状态码来重定向客户端的 POST 请求，在它后面跟上一个 GET 请求）。

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

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 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 服务器错误状态码

状态码	缘由短语	含义
500	Internal Server Error	服务器遇到一个妨碍它做为请求提供服务的错误时，使用此状态。
501	Not Implemented	客户端发起的请求超过服务器能力范围（好比，使用了服务器不支持的请求方法）时，使用此状态。
502	Bad Gateway	做为代理或网关使用的服务器从请求响应链的下一条链路上收到了一条伪响应（好比，他没法链接到父网关）时，使用此状态。
503	Service Unavailabe	用来讲明服务器如今没法为请求提供服务，但未来能够。若是服务器知道何时资源会变为可用的，能够在响应中包含一个 Retry-After 首部。
504	Gateway Timeout	与状态码408相似，只是这里的响应来自一个网关或代理，它们在等待里一服务器对其请求进行响应超时了。
505	HTTP Version Not Supported	服务器收到的请求使用了它没法或不肯支持的协议版本时，使用此状态码。有些服务器应用程序会选择不支持早期版本的协议。

首部

####1.通用首部 有些首部时客户端和服务端都能使用，且提供了与报文相关的最基本信息，叫作通用首部。

通用信息首部

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

通用缓存首部

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

####2.请求首部

请求首部是只在请求报文中有意义的首部。

请求的信息性首部

首部	描述
Client-IP	提供了运行客户端的机器的IP地址。
From	提供了客户端用户的 Email 地址。（使用RFC 822 E-mail地址格式）
Host	给出了接受请求的服务器的主机名和端口号。
Referer	提供了包含当前请求 URI 的文档的 URL。
UA-Color	提供了与客户端显示器的现实颜色有关的信息。
UA-CPU	提供了客户端 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	若是服务器支持范围请求，就请求资源的指定范围。

安全请求首部

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

代理请求首部

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

####3.响应首部

#####响应的信息性首部

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

#####协商首部

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

#####安全响应首部

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

####4.实体首部

实体首部提供了有关实体及其内容的大量信息，请求和响应报文中均可能包含实体部分，因此这两类报文均可能出现这些首部。总之，实体首部能够告知报文的接收者它在对什么进行处理。

#####实体的信息性首部

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

#####内容首部

内容首部提供了与实体内容有关的特定信息，说明了其类型，尺寸以及处理它所须要的其它有用信息。

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

#####实体缓存首部

通用的缓存首部说明了如何或者何时进行缓存。实体的缓存首部提供了与被缓存实体有关的信息。

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