共计 5216 个字符，预计需要花费 14 分钟才能阅读完成。
1. Method
请求方法，表明客户端希望服务器对资源执行的动作；
1.1 GET
向服务器请求资源。
1.2 HEAD
和 GET 方法的行为类似，但服务器在响应中只返回首部，不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。
可以做到：
- 不获取资源的情况下了解资源的情况 (比如，判断器类型)
- 通过查看响应中的状态码，看看某个对象是否存在；
- 通过查看首部，测试资源是否被修改了；
1.3 PUT
与 GET 从服务器读取文件相反，PUT 方法回向服务器写入文件。有些发布系统允许用户创建 WEB 页面，并用 PUT 直接将其安装到 WEB 服务器上；
PUT 方法的语义就是让服务器用请求的主体部分来创建一个由所请求的 URL 命令的新文档，或者如果那个 URL 已经存在的话，就用这个主体来代替它；
因为 PUT 允许用户对内容进行修改，所以很多 WEB 服务器都要求在执行 PUT 之前，用密码登录。
1.4 POST
向服务器发送要处理的数据；
一般服务器通常提供一个表单，客户端填入数据后点击提交 (提交是数据都会放在请求报文的实体部分当中)，然后由服务器将其发送到它要去的地方（比如，送到一个服务器的网关程序中，然后由这个程序对其进行处理）；
1.5 TRACE
客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在最终将请求发给服务器时，看看它变成了什么样子；
TRACE 请求会在目的服务器发起一个“环回”针对。行程最后一站的服务器会弹出一条 TRACE 响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看所有中间 HTTP 应用程序组成的请求 / 响应链上，原始包文是否, 以及如何被毁坏或修改过；
TRACE 方法主要用于诊断；也就是说，用于验证请求是否如愿的穿过了请求 / 响应链。它是一种很好的工具，可以用来查看代理和其他应用程序对用户请求所产生的效果。
尽管 TRACE 可以很方便的用于诊断，但是它确实也有缺点，它假定中间应用程序对各种不同类型请求（GET、HEAD、POST 等）的处理是相同的。很多 HTTP 应用程序会根据方法的不同做出不同的事情，比如，代理可能会将 POST 请求直接发给服务器，而将 GET 请求发送给另一个 HTTP 应用程序（比如 WEB 缓存）。TRACE 并不提供区分这些方法的机制。通常，中间应用程序会自行决定对 TRACE 请求的处理方式。
TRACE 请求中不能带有实体的主体部分。TRACE 响应的实体主体部分包含了响应服务器收到的请求的精确副本。
1.6 DELETE
DELETE 方法所做的事情就是请求服务器删除请求 URL 所指定的资源。但是客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求。
1.7 扩展方法
2 状态返回码
1xx：100-101,（额外）信息提示类的状态码；
2xx：200-206, 成功类的状态码；
3xx：300-305, 重定向类的状态码；没有把请求的页面响应给客户端，而是重定向到其它地方，或是无需获取此资源；
4xx：400-415, 错误类信息，客户端的错误类的状态码；例如请求不存在的资源；
5xx：500-505, 错误类信息，服务器端错误类的状态码；例如服务器内部的问题，因为资源有语法错误运行部成功，无法响应，不是资源不存在；
2.1 200~299– 成功状态码
200：OK
成功，请求的所有数据通过响应报文的 entity-body 部分发送；原因短语为 OK；
201：Created
用于创建服务器对象的请求（比如，PUT）。响应实体主体部分中应该包含各种引用了已创建的资源的 URL。Location 首部包含的则是最具体的引用。服务器必须在发送这个状态码之前创建好对象；
202：Accepted
请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会完成这个请求；这只是意味着接受请求时，他看起来是有效的。服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计（或者包含一个指针，指向可以获取此信息的位置）；
203：Non-Authoritative Information
实体首部包含的信息不是来自于源端服务器，而是来自资源的一份副本。如果中间节点上有一份资源副本，但无法或者没有对它所发送的与资源有关的原信息（首部）进行验证，就会出现这种情况；
这种响应吗并不是非用不可的；如果实体首部来自源端服务器，相应为 200 状态的应用程序就可以将其作为一种可选项使用；
204：No Content
响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主要用于在浏览器不转为显示新文档的情况下，对其进行更新（比如刷新一个表单页面）；
205：Rest Content
另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所有 HTML 表单元素；
206：Partial Content
成功执行了一个部分或 Range（范围）请求。客户端可以通过一些特殊的首部来获取部分或某个范围内的文档 – 这个状态码就说明范文请求成功了；
206 相应中必须包含 Content-Range、Date 以及 ETag 或 Content-Location 首部；
2.2 300~399– 重定向状态码
可以通过某些重定向状态码对浏览器本地缓存的资源副本与远端服务器上的资源进行验证。比如：用来查看本地的副本是否仍为最新的，或者远端服务器上的资源是否被修改过；
下图是客户端发送了一个特殊的 if-Modified-Since 首部，说明会读取 1997 年 10 月之后修改过的文档。因为这个日期之后，此文档并未修改过，因此，服务器回送了一个 304 状态码，而不是文档的内容；
300：Multiple Choices
客户端请求一个实际指向多个资源的 URL 时就会返回这个状态码，比如服务器上有某个 HTML 文档的英语和法语版本。返回这个代码时会带有一个选项列表；这样用户就可以选择他希望使用的那一项了。
301：Move Permanently
请求的 URL 指向的资源已经被删除（移动到其它位置）是永久重定向，资源被永久删除；但在响应报文中通过首部 Location 指明了资源现在所处的新位置；原因短语为 Moved Permanently；
302：Found
与 301 相似，但在响应报文中通过 Location 指明资源现在所处临时新位置，资源不是永久删除，是临时重定向; 原因短语为 Found；
303：See Other
告知客户端应该用另一个 URL 来获取资源。新的 URL 位于响应报文的 Location 首部。其主要目的是允许 POST 请求的响应将客户端定向到某个资源上去；
304：Not Modified
客户端发出了条件式请求，但服务器上的资源未曾发生改变，则通过通过此响应状态码通知客户端（带有这个状态码的响应不应该包含实体的主体部分），客户端可继续使用本地网页缓存；原因短语为 Not Modified；
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.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 版本了。
2.3 400~499– 客户端错误状态码
400：Bad Request
告知客户端它发送了一个错误的请求；
401：Unauthorized
与适当的首部一同返回，在这些首部中要求客户端在访问资源之前，需要进行认证（如基于 basic 认证时就是 401）。
402：Payment Required
保留
403：Forbidden
用于说明请求被服务器拒绝了。如果服务器想说明为什么拒绝请求，可以在包含请求实体的主体部分来对原因进行描述。但这个状态码通常是在服务器不想说明拒绝原因的时候使用的；
404：Not Found
用于说明服务器无法找到所请求的 URL。通常会包含一个实体，以便客户端应用程序显示给用户看；
405：Methord Not Allowed
发起的请求中带有所请求的 URL 不支持的方法时，使用此状态吗。应该在响应中包含 Allow 首部，已告知客户端对所请求资源可以使用哪些方法。
406：Not Acceptable
客���端可以指定参数来说明它们愿意接受什么类型的实体。服务器没有与客户端可接受的 URL 相匹配的资源时，使用此代码。通常，服务器会包含一些首部，以便客户端弄清楚为什么请求无法满足。
407：Porxy Authentication Required
与 401 状态码类似，但用于要求对资源进行认证的代理服务器；
408：Request Timeout
如果客户端完成请求所花的时间太长，服务器可以回送此状态码，并关闭连接。超时时长随着服务器的不同有所不同，但通常对所有的合法请求来说，都是够长的；
409：Conflict
用于说明请求可能在资源上引发的一些冲突。服务器担心请求会引发冲突时，可以发送此状态码。响应中应该包含描述冲突的主体；
410：Gone
与 404 类似，只是服务器曾经拥有过此资源。主要用于 WEB 站点的维护，这样服务器的管理员就可以在资源被移除的情况下通知客户端了；
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 请求首部包含了一个期望，但服务器无法满足此期望时，使用此状态码。
如果代理或其他中间应用程序有确切证据说明源端服务器会为其请求产生一个失败的期望，就可以发送这个响应状态码
2.4 500~599– 服务器错误状态码
500：Internal Server Error
服务器内部错误。
501：Not Implemented
客户端发起的请求超出了服务器的能力范围（比如，使用了服务器不支持到的请求方法）。
502：Bad Gateway
作为代理或网关使用的服务器从请求相应链的下一跳链路上收到了一条伪相应（比如，它无法连接到其父网关）。
503：Service Unavailable
用来说明服务器现在无法为请求提供服务，但捡来可以。如果服务器知道什么时候资源会变为可用的，可用在响应中包含一个 Retry-After 首部。
504：Gateway Timout
与状态码 408 类似，只是这里的响应来自一个网关或代理，他们在等待另一个服务器对其请求的进行响应时超时了。
505：HTTP Version Not Supported
服务器收到了请求，是它无法或不愿支持的协议版本时，使用此状态码（有些服务器应用程序会选择不支持协议的早期版本）。
：
