HTTP之方法与状态码

1. 方法

注意，不是每个服务器都实现了所有的方法。如果一台服务器要与 HTTP 1.1 兼容，那么只要为其资源实现 GET 方法和 HEAD 方法就可以了。

即使服务器实现了所有的这些方法，这些方法的使用很可能也是受限的。如，支持 DELETE 方法或者 PUT 方法的服务器可能并不希望任何人都能够删除或存储资源。

1.1 安全方法

GET 方法和 HEAD 方法都被认为是安全的方法，这就意味着使用 GET 或 HEAD 方法的 HTTP 请求都不会产生什么动作。

不产生动作，在这里意味着 HTTP 请求不会在服务器上产生什么结果。安全方法并不一定是什么动作都不执行（实际上，这是由 Web 开发者决定的）。使用安全方法的目的就是允许 HTTP 应用程序开发者通知用户，什么时候会使用某个可能引发某些动作的不安全方法。

1.2 GET

GET 方法通常用于请求服务器发送某个资源。HTTP/1.1 要求服务器实现此方法。如下示例，客户端用 GET 方法发起了一次 HTTP 请求。

1.3 HEAD

HEAD 方法与 GET 方法的行为很类似，但服务器在响应中只返回首部。不会返回实体的主体部分。这就允许客户端在未获取实际资源的情况下，对资源的首部进行检查。使用 HEAD，可以：

  • 在不获取资源的情况下了解资源的情况（如，判断其类型）；
  • 通过查看响应中的状态码，看看某个对象是否存在；
  • 通过产看首部，测试资源是否被修改了。

服务器开发者必须确保返回的首部与 GET 请求所返回的首部完全相同。遵循 HTTP/1.1 规范，就必须实现 HEAD 方法。如下示例：

1.4 PUT

与 GET 从服务器读取文档相反，PUT 方法会向服务器写入文档。有些发布系统允许用户创建 Web 页面，并用 PUT 直接将其安装到 Web 服务器上去。

PUT 方法的语义就是让服务器用请求的主体部分来创建一个由所请求的 URL 命名的新文档，或者，如果那个 URL 已经存在的话，就用这个主体来替代它。

因为 PUT 允许用户对内容进行修改，所以很多 Web 服务器都要求在执行 PUT 之前，用密码登录。

1.5 POST

POST 方法起初是用来向服务器输入数据的。实际上，通常会用它来支持 HTML 的表单。表单中填好的数据通常会被送给服务器，然后由服务器将其发送到它要去的地方（如，送到一个服务器网关程序中，然后由这个程序对其进行处理）。如下示例显示了一个用 POST 方法发起 HTTP 请求--向服务器发送表单数据--的客户端。

注：POST 用于向服务器发送数据。PUT 用于向服务器上的资源（如文件）中存储数据。

1.6 TRACE

客户端发起一个请求时，这个请求可能要穿过防火墙、代理、网关或其他一些应用程序。每个中间节点都可能会修改原始的 HTTP 请求。TRACE 方法允许客户端在最终将请求发送给服务器时，看看它变成了什么样子。

TRACE 请求会在目的服务器端发起一个 "环回" 诊断。行程最后一站的服务器会弹回一条 TRACE 响应，并在响应主体中携带它收到的原始请求报文。这样客户端就可以查看在所有中间 HTTP 应用程序组成的请求/响应链上，原始报文是否，以及如何被毁坏或修改过。

TRACE 方法主要用于诊断，即用于验证请求是否如愿穿过了请求/响应链。

TRACE 的缺点：它假定中间应用程序对各种不同类型请求（不同的方法--GET、HEAD、POST 等）的处理是相同的。很多 HTTP 应用程序会根据方法的不同做出不同的事情--如，代理可能会将 POST 请求直接发送给服务器，而将 GET 请求发送给另一个 HTTP 应用程序（如 Web 缓存）。TRACE 并不提供区分这些方法的机制。通常，中间应用程序会自行决定对 TRACE 请求的处理方式。

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

1.7 OPTIONS

OPTIONS 方法请求 Web 服务器告知其支持的各种功能。可以询问服务器通常支持哪些方法，或者对某些特殊资源支持哪些方法。（有些服务器可能只支持对一些特殊类型的对象使用特定的操作）。

1.8 DELETE

DELETE 方法所做的事情就是请服务器删除请求 URL 所指定的资源。但是，客户端应用程序无法保证删除操作一定会被执行。因为 HTTP 规范允许服务器在不通知客户端的情况下撤销请求。

1.9 扩展方法

扩展方法指的就是没有在 HTTP/1.1 规范中定义的方法。服务器会为它所管理的资源实现一些 HTTP 服务，这些方法为开发者提供了一种扩展这些 HTTP 服务能力的手段。

如下为 Web 发布扩展方法示例：

  • LOCK：允许用户 "锁定" 资源 -- 如，可以在编辑某个资源的时候将其锁定，以防别人同时对其进行修改。
  • MKCOL：允许用户创建资源。
  • COPY：便于在服务器上复制资源。
  • MOVE：在服务器上移动资源。

并不是所有的扩展方法都是在正式规范中定义的。

2. 状态码

2.1 100~199 -- 信息性状态码

HTTP/1.1 向协议中引入了信息性状态码。

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

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

1. 客户端与 100 Continue

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

客户端应用程序只有在避免向服务器发送一个服务器无法处理或使用的大实体时，才应该使用 100 Continue。

发送了值为 100 Continue 的 Expect 首部的客户端不应该永远在那儿等待服务器发送 100 Continue 响应。超时一定时间之后，客户端应该直接将实体发送出去。

2. 服务器与 100 Continue

如果服务器收到了一条带有值为 100 Continue 的 Expect 首部的请求，它会用 100 Continue 响应会一条错误码来进行响应。服务器永远也不应该向没有发送 100 Continue 期望的客户端发送 100 Continue 状态码。

如果出于某种原因，服务器在有机会发送 100 Continue 响应之前就收到了部分（或全部）的实体，就说明客户端已经决定继续发送数据了，这样，服务器就不需要发送这个状态码了。但服务器读完请求之后，还是应该为请求发送一个最终状态码（即跳过了 100 Continue 状态）。

如果服务器收到了带有 100 Continue 期望的请求，而且它决定在读取实体的主体部分之前（如，因为出错而）结束请求，就不应该仅仅是发送一条响应并关闭连接，因为这样会妨碍客户端接收响应。

3. 代理与 100 Continue

如果代理从客户端收到了一条带有 100 Continue 期望的请求，它需要做几件事请。如果代理知道下一跳服务器是 HTTP/1.1 兼容的，或者并不知道下一跳服务器与那个版本兼容，它都应该将 Expect 首部放在请求中向下转发。如果它知道下一跳服务器只能与 HTTP/1.1 之前的版本兼容，就应该以 417 Expectation Failed 错误进行响应。

如果代理决定代表与 HTTP/1.0 或之前版本兼容的客户端，在其请求中放入 Expect 首部和 100 Continue 值，那么，（如果它从服务器收到了 100 Continue 响应）它就不应该将 100 Continue 响应转发给客户端，因为客户端可能不知道该拿它怎么办。

2.2 200~299 -- 成功状态码

  • 200：OK。请求没问题，实体的主体部分包含了所请求的资源。
  • 201：Created。用于创建服务器对象的请求（比如，PUT）。响应的实体主体部分中应该包含各种引用了已创建的资源的 URL，Location 首部包含的则是最具体的引用。服务器必须在发送这个状态码之前创建好对象。
  • 202：Accepted：请求已被接受，但服务器还未对其执行任何动作。不能保证服务器会完成这个请求；这只是意味着接受请求时，它看起来是有效的。服务器应该在实体的主体部分包含对请求状态的描述，或许还应该有对请求完成时间的估计（或者包含一个指针，指向可以获取此信息的位置）。
  • 203：Non-Authoritative Information。实体首部包含的信息不是来自于源端服务器，而是来自资源的一份副本。如果中间节点上有一份资源副本，但无法或者没有对它所发送的与资源有关的元信息（首部）进行验证，就会出现这种情况。
  • 204：No Content。响应报文中包含若干首部和一个状态行，但没有实体的主体部分。主要用于在浏览器不转为显示新文档的情况下，对其进行更新（比如刷新一个表单页面）。
  • 205：Reset Content。另一个主要用于浏览器的代码。负责告知浏览器清除当前页面中的所有 HTML 表单元素。
  • 206：Partial Content。成功执行了一个部分或 Range（范围）请求。客户端可以通过一些特殊的首部来获取部分或某个范围内的文档--这个状态码就说明范围请求成功了。206 响应中必须包含 Content-Range、Date 以及 ETag 或 Content-Location 首部。

2.3 300~399 -- 重定向状态码

重定向状态码要么告知客户端使用替代位置来访问它们所感兴趣的资源，要么就提供一个替代的响应而不是资源的内容。如果资源已被移动，可发送一个重定向状态码和一个可选的 Location 首部来告知客户端资源已被移走，以及现在可以在哪里找到它。这样，浏览器就可以在不打扰使用者的情况下，透明地转入新的位置了。

可以通过某些重定向状态码对资源的应用程序本地副本与源端服务器上的资源进行验证。如，HTTP 应用程序可以查看其资源的本地副本是否仍然是最新的，或者在源端服务器上资源是否被修改过。如下示例，客户端发送了一个特殊的 If-Modified-Since 首部，说明只读取 1997 年 10 月之后修改过的文档。这个日期之后，此文档并未被修改过，因此，服务器回送一个 304 状态码，而不是文档的内容。

  • 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 首部给出。很重要的一点是，客户端是相对某个特定资源来解析这条响应的，不能假定所有请求，甚至所有对持有所请求资源的服务器的请求都通过这个代理进行。如果客户端错误地让代理介入了某条请求，可能会引发破坏性的行为，而且会造成安全漏洞。
  • 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 规范使用 303 状态码来实现同样的行为（服务器发送 303 状态码来重定向客户端的 POST 请求，在它后面跟上一个 GET 请求）。

对于 HTTP/1.1 客户端，用 307 状态码取代 302 状态码来进行重定向。这样服务器就可以将 302 状态码保留起来，为 HTTP/1.0 客户端使用。

2.4 400~499 -- 客户端错误状态码

有时客户端会发送一些服务器无法处理的东西，如格式错误的请求报文，或者是请求一个不存在的 URL。

  • 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：与 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 请求首部包含了一个期望，但服务器无法满足此期望时，使用此状态码。

2.5 500~599 -- 服务器错误状态码

  • 500：Internal Server Error。服务器遇到一个妨碍它为请求提供服务的错误时，使用此状态码。
  • 501：Not Implemented。客户端发起的请求超出服务器的能力范围（如，使用了服务器不支持的请求方法）时，使用此状态码。
  • 502：Bad Gateway。作为代理或网关使用的服务器从请求响应链的下一条链路上收到了一条伪响应（比如，它无法连接到其父网关）时，使用此状态码。
  • 503：Service Unavailable。用来说明服务器现在无法为请求提供服务，但将来可以。如果服务器知道什么时候资源会变为可用的，可以在响应中包含一个 Retry-After 首部。
  • 504：Gateway Timeout。与状态码 408 类似，只是这里的响应来自一个网关或代理，它们在等待另一服务器对其请求进行响应时超时了。
  • 505：HTTP Version Not Supported。服务器收到的请求使用了它无法或不愿支持的协议版本时，使用此状态码。有些服务器应用程序会选择不支持协议的早期版本
posted @ 2018-07-07 09:18  季末的天堂  阅读(553)  评论(0)    收藏  举报