HTTP
报文
HTTP报文包括3部分：
- 起始行
- 首部字段：名字和值以
:区分，每个首部字段以\r\n换行分割。首部以一个空行表示结束。 - 主体
请求报文起始行结构：
- 方法(method): GET是这个请求的方法。
- 请求URL(request-URL): 这个request所请求的资源。
- 版本(version): 请求报文所用的HTTP版本，格式为
HTTP/。.
响应报文起始行结构：
- 版本(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 | 这个实体最后一次被修改的日期和时间。 |