http 方法定义 method defined 状态码Status Code Definitions

OPTIONS（选项）

　　OPTIONS 方法表明请求想得到请求/响应链上关于此请求里的 URI（Request-URI）指定资源的通信选项信息。此方法允许客户端去判定请求资源的选项和/或需求，或者服务器的能力，而不需要利用一个资源动作（译注：使用 POST，PUT，DELETE 方法）
或一个资源获取（译注：用 GET 方法）方法。此方法的响应是不能缓存的.
　　如果 OPTIONS 请求消息里包括一个实体主体（当请求消息里出现 Content-Length 或者Transfer-Encoding 头域时），那么媒体类型必须通过 Content-Type 头域指明。虽然此规范没有定义如何使用此实体主体，将来的 HTTP 扩展可能会利用 OPTIONS 请求的消息主体去得到服务器得更多信息。一个服务器如果不支持 OPTION 请求的消息主体，它会遗弃此请求消息主体。
    如果请求 URI 是一个星号（"*"）,，OPTIONS 请求将会应用于服务器的所有资源而不是特定资源。因为服务器的通信选项通常依赖于资源，所以”*”请求只能在“ping”或者“no-op”方法时才有用；它干不了任何事情除了允许客户端测试服务器的能力。
例如：它能被用来测试代理是否遵循 HTTP/1.1。
　　如果请求 URI 不是一个星号（"*"）,，OPTIONS 请求只能应用于请求 URI 指定资源的选项。200 响应应该包含任何指明选项性质的头域，这些选项性质由服务器实现并且只适合那个请求的资源（例如，Allow 头域），但也可能包一些扩展的在此规范里没有定义的头域。
    如果有响应主体的话也应该包含一些通信选项的信息。这个响应主体的格式并没有在此规范里定义，但是可能会在以后的 HTTP 里定义。内容协商可能被用于选择合适的响应格式。
    如果没有响应主体包含，响应就应该包含一个值为“0”的 Content-Length 头域。
    Max-Forwards 请求头域可能会被用于针对请求链中特定的代理。当代理接收到一个 OPTIONS请求，且此请求的 URI 为 absoluteURI，并且此请求是可以被转发的，那么代理必须要检测Max-Forwards 头域。
    如果 Max-Forwards 头域的值为“0”，那么此代理不能转发此消息；而是代理应该以它自己的通信选项响应。如果 Max-Forwards 头域是比 0 大的整数值，那么代理必须递减此值当它转发此请求时。如果没有 Max-Forwards 头域出现在请求里，
那么代理转发此请求时不能包含 Max-Forwards 头域

GET   

　　GET 方法意思是获取被请求 URI（Request-URI）指定的信息（以实体的格式）。如果请求URI 涉及到一个数据生成过程，那么这个过程生成的数据应该被作为实体在响应中返回而不是
过程的源文本，除非源文本恰好是过程的输出。
    如果请求消息包含 If-Modified-Since,，If-Unmodified-Since，If-Match，If-None-Match 或者If-Range 头域，GET 的语义将变成“条件（conditionall） GET”。一个条件 GET 方法会请求满
足条件头域的实体。条件 GET 方法的目的是为了减少不必要的网络使用，这通过允许利用缓存里仍然保鲜的实体而不用多次请求或传输客户端已经拥有的实体来实现的。

HEAD
    HEAD 方法和 GET 方法一致，除了服务器不能在响应里返回消息主体。HEAD 请求响应里HTTP 头域信息，应该和 GET 请求响应里的头域信息一致。
    此方法被用来获取请求实体的元信息而不需要传输实体主体（entity-body）。此方法经常被用来测试超文本链接的有效性，可访问性，和最近的改变。.
    HEAD 请求的响应是可缓存的，因为响应里的信息可能被缓存用于更新以前那个资源对应缓存的实体.。
    如果出现一个新的域值指明缓存的实体和当前源服务器上的实体有所不同（可能因为Content-Length，Content-MD5，ETag 或 Last-Modified 值的改变），那么缓存（cache）必须认为缓存项是过时的（stale）

 POST

POST 方法被用于请求源服务器接受请求中的实体作为请求资源的一个新的从属物。 POST 被设计涵盖下面的功能。

• --已存在的资源的注释；
• --发布消息给一个布告板，新闻组，邮件列表，或者相似的文章组。
• --提供一个数据块，如提交一个表单给一个数据处理过程。
• --通过追加操作来扩展数据库。

    POST 方法的实际功能是由服务器决定的，并且经常依赖于请求 URI（Request-URI）。POST提交的实体是请求 URI 的从属物，就好像一个文件从属于一个目录，一篇新闻文章从属于一个
新闻组，或者一条记录从属于一个数据库。POST 方法执行的动作可能不会对请求 URI 所指的资源起作用。在这种情况下，200（成功）或者 204（没有内容）将是适合的响应状态，这依赖于响应是否包含一个描述结果的实体。
    如果资源被源服务器创建，响应应该是 201（Created）并且包含一个实体，此实体描述了请求的状态。并且引用了这个新资源和一个 Location 头域。
POST 方法的响应是不可缓存的。除非响应里有合适的 Cache-Control 或者 Expires 头域。然而，303（见其他）响应能被用户代理利用去获得可缓存的响应。

PUT

    PUT 方法请求服务器去把请求里的实体存储在请求 URI（Request-URI）标识下。如果请求URI（Request-URI）指定的的资源已经在源服务器上存在，那么此请求里的实体应该被当作是源服务器关于此 URI 所指定资源实体的最新修改版本。
    如果请求 URI（Request-URI）指定的资源不存在，并且此 URI 被用户代理定义为一个新资源，那么源服务器就应该根据请求里的实体创建一个此 URI 所标识下的资源。如果一个新的资源被创建了，源服务器必须能向用户代理（user agent） 发送 201（已创建）响应。如果已存在的资源被改变了，那么源服务器应该发送 200（Ok）或者 204（无内容）响应。如果资源不能根据请求 URI 创建或者改变，一个合适的错误响应应该给出以反应问题的性质。实体的接收者不能忽略任何它不理解和不能实现的Content-*（如：Content-Range）头域，并且必须返回 501（没有被实现）响应。
    如果请求穿过一个缓存（cache），并且此请求 URI（Request-URI）指示了一个或多个当前缓存的实体，那么这些实体应该被看作是旧的。PUT 方法的响应是不可缓存的。

POST 方法和 PUT 方法请求最根本的区别是请求 URI（Request-URI）的含义不同。

• 　　POST 请求里的 URI 指示一个能处理请求实体的资源（译注：此资源可能是一段程序，如 jsp 里的servlet） 。此资源可能是一个数据接收过程，一个网关（gateway，译注：网关和代理的区别是：网关可以进行协议转换，而代理不能，只是起代理的作用，比如缓存服务器其实就是一个代理），或者一个单独接收注释的实体。对比而言，PUT 方法请求里的 URI 标识请求里封装的实 体 一 一 用 户 代 理 知 道 URI 意 指 什 么 ， 并 且 服 务 器 不 能 把 此 请 求 应 用 于 其 它 资 源（resource）。如果服务器期望请求被应用于一个不同的 URI，那么它必须发送 301（永久移动）响应；用户代理可以自己决定是否重定向请求。一个单独的资源可能会被许多不同的 URI 指定。如：一篇文章可能会有一个 URI 指定当前版本，而这个 URI 区别于这篇文章其它特殊版本的 URI。这种情况下，对一个通用 URI 的 PUT 请求可能会导致其资源的其它 URI 请求被源服务器重定义

响应码

200 OK

 

• 此状态码指明客户端请求已经成功了。响应返回的信息依赖于请求里的方法，例如：
• GET 请求资源的相应的实体已经包含在响应里并返回给客户端。
• HEAD 相应于请求资源实体的实体头域已经被包含在无消息主体的响应里。
• POST 响应里已经包含一个实体，此实体描述或者包含此 POST 动作执行的结果

 

201 已创建（Created）　　

　　请求已经被服务器满足了并且已经产生了一个新的资源。新创建的资源的 URI 在响应的实体里返回，但是此资源最精确的 URI 是在 Location 头域里给出的。响应应该含有一实体，此实体包
含此资源的特性和位置，用户或用户代理能从这些特性和位置里选择最合适的。实体格式被Content-Type 头域里媒体类型指定。源服务器必须能在返回 201 状态码之前建立资源。如果动
作（译注：这里指能创建资源的方法，如 POST 方法）不能被立即执行，那么服务器应该以202（接受）响应代替。一个 201 响应可以包含一个 ETag 响应头域，此头域的值指明了当前请求变量也即刚刚创建的资源的实体标签（entity tag）值

202 接受（Accepted）

　　请求已经被接受去处理，但是还没有处理完成。请求可能会或者不会处理完成，因为存在当处理的过程中拒绝处理的情况。202 响应是有意非担保性的。它是为了允许服务器可以为其它处理（如：每天执行一次的批处
理）接收请求而不需要用户代理在处理没有完成之前长期连接到服务器。响应里的实体应该包含请求当前状态的声明并且应该包含一个状态监视指针或一些用户期望何时请求被满足的评估值。

203 非权威信息（Non-Authoritative information）  

 　　此状态码响应指明响应里实体头域元信息不能从源服务器获而是从本地的或第三方响应副本里收集的。这些元信息可能是源服务器版本的子集或超集。如，包含一个存在本地的资源注释信息就可以产生一个源服务器能理解的元信息的超集。

利用此响应状态码不是必须但是比200（Ok）响应却更加合适。

 204 无内容 （No Content）

服务器已经满足了请求但并没有返回一个实体而是返回更新的元信息。此响应可能包含新的或更新的元信息以实体头域的形式，这些元信息应该相关于请求变量。
利用此 204 响应，客户端如果是一个用户代理，它就可以不用改变引起请求发送的文档视图（译注：如一篇 html 文档在浏览器里呈现的样子）。204 状态响应主要的目的是允许输入，而
不必引起用户代理当前文档视图的改变，尽管一些新的或更新了的元信息可能会应用于用户代理视图里的当前文档。
204 响应不能包含一个消息主体，并且在头域后包含一个空行结束

205 重置内容（Reset Content）

205 状态响应是服务器告诉用户代理应该重置引起请求被发送的文档视图。此响应主要的目的
是清空文档视图表单里的输入框以便用户能输入其它信息。此响应不能包含一个实体。

206 部分内容（Partial Content）

服务器已经完成了客户端对资源的部分 GET 请求。请求必须包含一个 Range 头域用来指出想要的范围，并且也有可能包含一个 If-Range 头域来使请求成为一个条件请求。206 状态的响应必须包含以下的头域：
- 或者含有一个 Content-Range 头域，此头域指明了响应里的范围；或者含有一个值为“multipart/byteranges”的 Content-Type 头域并且每部分包含 Content-Range 头域。如果一个Content-Length 头域出现在响应里，它的值必须是实际传输的消息主体的字节数。
- Date 头域
- ETag 和/或 Content-Location 头域，如果这些头域假设在相同请求的 200 响应里也会出现的话。
- Expire，Cache-Control，和/或者 Vary 头域，如果这些头域的域值与以前同一变量响应中的不一样。
如果 206 响应是使用了强缓存验证（见 13.3.3）的 If-Range 请求的结果，那么此响应不应该包含其他的实体头域。如果响应是使用了弱缓存验证的 If-Range 请求的结果，那么响应必须不
能包含其他的实体头域；这能防止缓存里缓存的实体主体与更新头域之间的不一致性。另外，响应必须包含假设在相同请求的 200 响应里的所有实体头域。缓存不能把 206 响应和以前的缓存内容相合并如果 ETag 或 Last-Modified 头域并不能精确匹配，
一个不能支持 Range 和 Content-Range 头域的缓存不能缓存 206（部分的）响应

 

重新定向 3xx.

这类状态码指明用户代理需要更进一步的动作去完成请求。进一步的动作可能被用户代理自动执行而不需要用户的交互，并且进一步动作请求的方法必须为 GET 或 HEAD。一个客户端应该发现无限的重定向循环，因为此循环能产生网络拥挤

300 多个选择.（Multiple Choices）

301 永久移动 （Moved Permanently）

　　请求资源被赋于一个新的永久的 URI，并且任何将来对此资源的引用都会利用此 301 状态响应返回的 URI。具有链接编辑能力的客户端应该能自动把请求 URI 的引用转到到服务器返回的新的引用下。

此响应是能缓存的除非另外声明 .

　　新的永久 URI 应该在响应中被 Location 头域给定。除非请求方法是 HEAD，否则此响应应该包含一个超文本提示和一个指向新 URI 的超文本链接。

如果客户端接收了一个来自非 GET 或 HEAD 请求方法的 301 响应，那么用户代理不能自动重定向请求除非它能被用户确认，因为这可能会改变请求提交的条件。

注意：当客户端在接收了 301 状态码响应后，会重定向 POST 请求，一些已经存在的HTTP/1.0 用户代理会错误的把此请求变成一个 GET 请求。

302 发现(Found)

　　请求的资源暂时地存放在一个不同的 URI 下。因为重定向的地址可能有时会被改变，客户端应该继续为将来的请求利用请求 URI(Request-URI)。302 响应是只有在 Cache-Control 或 Expires头域指明的情况下才能被缓存。
临时的 URI 应该在 Location 头域里指定。除非请求方法是 HEAD，否则此响应应该包含一个超文本提示和一个指向新 URI 的超文本链接

303 见其他(See Other)

　　请求的响应被放在一个不同的 URI 下，并且应该用 GET 方法获得那个资源。此方法的存在主要是让 POST 调用脚本的输出能使用户代理重定向到一个选择的资源。新的 URI 并不是原始请求资源的代替引用。

303 响应不能被缓存，但是再次重定向请求的响应应该被缓存 .

304 没有改变（Not Modified）

　　如果客户端已经执行了条件 GET 请求，并且访问服务器的资源是允许的，但是服务器上的文档并没有被改变，那么服务器应该以此状态码响应。304 响应不能包含一个消息主体(messagebody)，并且在头域后面总是以一个空行结束。

此响应必须包含下面的头域：

 

• -Date，除非 某些（后续分析某些）指明的那些规则下 Date 是可以遗漏的。如果时钟不准确的源服务器遵循这些规则，并且代理和客户端在接收了一个没有 Date 头域的响应后加上了自己的 Date（这在RFC 2086 里声明了），缓存将会正确操作。
• ETag 和/或 Content-Location 头域，如果这些头域应在相同请求的 200 响应里出现的话。
• Expire，Cache-Control，和/或者 Vary 头域，如果这些头域值与以前同一变量响应中的不一致。

如果条件 GET 请求使用强缓存验证时，那么响应不应包含其它实体头域。当条件 GET 使用弱缓存验证时，那么响应必须不能包含其它实体头域；这能防止缓存的实体主体与更新的头域之间的不一致性。
如果一个 304 响应指示一个没有被缓存的实体，那么此缓存必须不用理会此响应，并且以无条件请求重试请求。
如果缓存利用一个接收到的 304 响应去更新一个缓存项，那么缓存必须用此响应响应里任何最新的域值更新缓存项。

 

 

305 使用代理 （Use Proxy）

请求资源必须能通过代理访问，代理的地址在响应的 Location 头域里指定。Location 头域指定了代理的 URI。接收者被期望通过代理重试此请求，305 响应必须被源服务器产生

306 没有使用的（unused）

被保留的返回码

307 临时重发（Temporary Redirect）

　　请求的资源临时存在于一个不同的 URI 下。由于重新向可能有时会改变，所以客户端应该继续利用此请求 URI（Request-URI）为将来的请求。307 响应只有被 Cache-Control 或 Expire 头域指明时才能被缓存。

客户端错误 4xx

　　状态码 4xx 类的目的是为了指明客户端出现错误的情况。除了当响应一个 HEAD 请求，服务器应该包含一个实体，此实体包含一个此错误请求的解释。此状态码对所有请求方法都是适合的。用户代理应该展示任何响应里包含的实体给用户  

400 坏请求（Bad Request）

　　请求不能被服务器理解，由于错误的语法。客户端不应该在没有改变请求的情况下重试请求。

401 未授权的 （Unauthorized）

　　服务器需要对请求进行用户认证。响应必须包含一个 WWW-Authenticate 头域

403 禁用 （Forbidden）

　　服务器理解此请求，但拒绝满足此请求。认证是没有作用的，并且请求不应该被重试。如果请求方法是 HEAD 并且服务器想让客户端知道请求为什么不能被满足，那么服务器起应该在响应实
体里描述此拒绝的原因。如果服务器不希望告诉客户端拒绝的原因，那么 404 状态码(NotFound)响应将被使用。

404 没有找到（Not Found）

　　服务器并没有找到任何可以匹配请求 URI 的资源。没有迹象表明条件是暂时或永久的 ，410（Gone）状态响应应该被使用，

如果服务器通过内部配置机制知道一个旧资源永远不能获得并且也没有转发地址。此状态码通常被使用，当服务器不希望精确指出请求为何被拒绝，或者当没有任何其它响应可用时。

405 方法不被允许（Method Not Allowed）

　　此状态码表示请求行（Request-Line）里的方法对此资源来说不被允许。响应必须包含一个Allow 头域，此头域包含以一系列对此请求资源有效的方法。

406 不可接受的 （Not Acceptable）

　　根据客户端请求的接受头域（译注：如：Accept, Accept-Charset, Accept-Encoding, 或者 AcceptLanguage），服务器不能产生让客户端可以接受的响应。

407 需要代理验证（Proxy Authentication Required）

　　此状态码和 401（Unauthorized）相似，但是指示客户端首先必须利用代理对自己验证

408 请求超时（Request Timeout）

　　客户端在服务器等待的时间里不能产生请求。客户端可能在以后会重试此请求

410 不存在（gone）

　　请求资源在源服务器上不再可得并且也没有转发地址可用。此条件被认为是永久的

411 长度必需 （Length Required）

　　服务器拒绝接受请求里没有包含 Content-Length 头域的请求。客户端可以重试此请求如果它添加了一个有效的 Content-Length 头域，此头域值指定了请求消息里消息主体的长度。

412 先决条件失败 （Precondition Failed）

　　在一个或多个请求头域里指定的先决条件当在服务器上测试为 false 时返回的响应。此响应允许客户端把先决条件放放到当前资源的元信息（头域数据）之上，这样能防止请求方法被应用于
一个非目的性的资源。

413 请求实体太大

　　服务器拒绝处理请求因为请求实体太大以致达到服务器不愿意去处理

414 请求 URI 太长（Request-URI Too Long）

　　服务器拒绝为请求服务因为此请求 URI 太长了以至于服务器不能解析。

415 不被支持的媒体类型（Unsupported Media Type）

　　服务器拒绝为请求服务，因为请求的实体的格式不能被此方法的请求资源所支持

416 请求范围不满足 （Requested Range Not Satisfiable）

　　服务器返回一个此状态码的响应，如果请求包含一个 Range 请求头域，并且此头域里 range-specifier 值没有和已选资源的当前 extent 值重叠，并且请求没有包含一个 IfRange 请求头域。
（对 byte-ranges 来说，这意味着 byte-range-spec 的所有 first-byte-pos值大于选择的资源的当前长度）。
当此状态码响应是在 byte-range 请求返回时，响应应该包含一个 Content-Range 实体头域用来指定已选资源的当前长度。响应不能使用 multipart/byteranges 媒体类型。

417 期望失败（Expectation Failed）

　　Expect 请求头域里指定的希望不能被服务器满足，或者，如果服务器是代理，那么能确定请求不能被下一站（next-hop）服务器满足。

 

 服务器错误 5xx （Server Error）

　　这类状态码指明服务器处理请求时产生错误或不能处理请求。除了 HEAD 请求，服务器应该包含一个实体，此实体用来解释错误，和是否是暂时或长期条件。用户代理应该展示实体给用户。此响应状态码能应用于任何请求方法。