服务器应答消息状态码

服务器应答消息状态码 以下我们将介绍各个状态码的含义，关于每个每个状态码的解释以它的三位数字开头， 随后是该状态码的简短解释，这种简短解释通常出现在状态行中。 7．1 信息状态码1xx 包含这类状态码的应答消息没有消息实体，只包含状态行和若干可选的头段，消息以一 个空行结束。 • 100 Continue。服务器已接收到客户的部分请求，客户可继续传送其余部分。 当客户传送带有消息实体的请求消息时，如果消息实体较长，而且客户不能肯定服务器 是否愿意接收这个实体，客户可先传送消息头，并且在其中包含头段 Expect：100-continue 服务器接收到这种消息后，如果愿意接收客户准备传送的实体，就可以用100作为应答消息的状态码。客户在收到应答后，可继续传送包含实体的请求消息。 • 101 Switching protocols。服务器同意客户改变协议的请求，并立即予以实施。 如果客户希望使用更好的应用层协议与服务器通信，客户可以在请求消息中用头段 Upgrade指出希望使用的协议。例如，假如某一天有了HTTP/2.0，但是还不是很流行，当前客户和服务器还在用HTTP/1.1通信。客户希望改为使用HTTP/2.0，于是可在请求消息中加上头段：Upgrade：HTTP/2.0，服务器接收到这个请求消息后，如果同意执行新的协议，就 可以用状态码101应答，并且在送出应答消息后立即使用新协议。 7．2 操作成功状态码2xx • 200 OK。用户的请求已被成功处理。 这种状态码的应答消息可能包含消息正文，也可能不包含，取决于所请求的操作。对于 GET，应答消息的消息正文将是所请求资源的一个实体。对于HEAD，没有消息正文，但是消息头包含所请求实体对应的实体头段。对于POST，消息正文是描述操作结果的实体，或 者是包含操作结果的实体。对于TRACE，消息正文是所接收到的请求消息。 • 201 Created。请求已执行并且新资源已创建。 当客户要求在服务器上创建一个新资源时（例如PUT），服务器如果同意请求并创建了 新资源，就用201应答。应答消息应该包含头段Location，指出新创建资源的URI。应答消息的正文是对新资源特性的描述，如果新资源有更多的URI的话，也包含在消息正文中。 服务器必须在新资源已创建之后才能用201应答。如果服务器只是准备创建，而一时还 来不及完成，则应该用202（Accepted）应答。 • 202 Accepted。请求已接受并正在处理，但处理尚未完成。 这种应答使得客户可以断开与服务器的连接，而不必保持连接等待服务器操作完成。但 是这种应答并不保证此后请求一定能够成功完成，客户不能以为收到这个应答事情就办成 了。 • 203 Non-Authoritative Information。非权威信息。 当应答消息中实体头段是从其它地方复制过来的时候，可以用这种应答。例如，客户和 服务器之间的缓存系统如果用本地保存的实体副本应答客户，但没有对其中的实体头段进行 验证，则可以发送这种应答。 • 204 No Content。无实体正文。 服务器已履行请求但没有必要返回实体正文。应答消息可能包含有实体头段，其中有更 新的信息。这种应答主要针对浏览器这类用户代理，当浏览器接收到这种应答时，不必切换 当前页面，只需按照应答消息中的实体头段刷新当前页面。 • 205 Reset Content。内容复位。 这种应答也是针对浏览器的。浏览器接收到这种应答，则说明先前提交的数据已被服务 器接收，现在应该复位单（Form）中的各种输入元素（输入框、选择按钮等）。 • 206 Partial Content。实体的部分内容。 当客户的请求消息包含头段Range指出希望获得实体的部分内容时而不是全部内 容时，服务器若满足要求，则在传送部分内容时使用这个状态码。 7．3 重定向状态码3xx 这类状态码通知客户，必须采取进一步的操作以完成请求，客户代理可以不询问用 户而直接采取下一步行动。 • 300 Multiple Choices。存在多种选择的资源。 客户请求消息中的URI可能对应多种资源，例如一个网站的主页可能有不同语言的版 本，服务器可在应答消息包含的实体中指出各种资源的位置，并且将服务器认为最合适 的资源URI放在头段Location中。 • 301 Moved Permanently。永久性的位置变更。 如果客户所请求的资源已经永久性地被指定了另一个URI，则服务器发送这种应答，并且在应答消息中包含头段Location，指出新的URI。如果客户请求的操作是GET或 HEAD，则用户代理可按照Location头段用新的URI自动重定向，对于其它操作则不能自动重定向，因为资源URI的变更可能改变了发起请求的条件。 • 302 Found。资源已找到。 当客户请求的资源临时存放在另一个URI指定的位置时，则服务器发送这种应答，并且在应答消息中包含头段Location，指出这个临时的URI。由于是临时的，所以用户代理在下一次请求同一资源时仍应使用原来的URI。类似301状态码，只有当请求操作为GET或HEAD时，用户代理才可以自动重定向。 • 303 See Other。参见其它。 对请求消息的应答可用另一个URI获得，应答消息应该有头段Location指出这个URI。客户收到这种应答后，应该用这个URI发出GET请求。这种状态码主要用于对 POST请求的应答，客户用POST请求提交数据后，服务器可用这种应答消息让客户程 序从另一处获得操作结果的有关信息。 • 304 Not Modified。资源未被修改。 如果客户的请求是条件获取，而所请求的资源未被修改的话，服务器就发送这种应 答。例如，客户发出GET请求，其中包含头段If-Modified-Since，而所请求的资源在这个头段指定的日期后未被修改过，则服务器返回这种状态码的应答消息。这种应答消息 不能有消息正文。 • 305 Use Proxy。使用代理服务器。 服务器用这种状态码指出，所请求的资源必须从代理服务器处获取。服务器在应答消息 中用头段Location指出代理服务器的URI，这个应答消息的接收者应该重发请求。 • 306 (Unused)。（不使用） 这个状态码不再使用，但由于先前的HTTP版本有这个状态码，所以仍保留。 • 307 Temporary Redirect。临时重定向。 这个状态码的功能与302（Found）完全相同。HTTP/1.1设置这个状态码是因为，之前的HTTP版本对302的解释与1.1版本不一致，如果应答消息的接收者执行先前版本，则302状态码可能引起误解。为此，服务器可使用307，先前版本的HTTP协议没有这个状态码。 7．4 客户错误状态码4xx • 400 Bad Request。错误请求。 客户发来的请求消息语法有错误，服务器无法理解。 • 401 Unauthorized。未经授权。 对于需要客户提供用户名、密码才能访问的资源，如果客户发来请求消息，其中没有包含证 明身份的Authrization头段，则服务器用401状态码应答，并且在应答消息中包含头段 WWW-Authenticate，这个头段包含一个“质询”（challenge），要求客户证明用户身份。客户 可重新发送包含请求消息，其中用Authrization头段提供身份证明，服务器对收到的身份证 明进行验证，若为合法用户，则向客户发送包含资源实体的应答消息，否则再次用401应答。 关于授权验证的详细情况，可参见第 节。 • 402 Payment Reuired。要求付款。 这个状态码被保留，留待以后的新版本使用。 • 403 Forbidden。访问被禁止。 服务器理解客户发来的请求，但拒绝执行。这种状态码意味着拒绝的原因不是身份验证 的问题，客户不应该再次发出相同的请求，即使包含身份证明的请求也没有用。如果客户的 请求操作不是HEAD，则服务器可在请求消息正文包含说明信息，指出拒绝访问的原因。如 果服务器不愿或无法说明原因，则应该改用状态码404（Not Found）应答。 • 404 Not Found。资源未找到。 服务器未找到请求URI对应的资源。这种应答没有指出资源是暂时不可用还是已丢弃，通 常是服务器拒绝访问又不愿说明原因的应答。如果服务器要通知客户资源已丢弃，则应该用 状态码410（Gone）应答。 • 405 Method Not Allowd。不允许所请求的操作。 对于请求消息的URI对应的资源，服务器不允许执行请求消息中的操作（Method）。对于这种状态码，服务器的应答消息中必须包含头段Allow，指出对于所请求的资源允许执行的操 作。 • 406 Not Acceptable。不可接受。 客户在请求消息中可以用Accept、Accept-Charset、Accept-Language等头段指出客户能够接受的媒体类型、字符编码、语言等实体特征，如果对于请求消息中URI对应的资源，服务器所能产生的实体不能满足客户所要求的特征，则服务器用这个状态码应答。服务器应 该在消息正文中指出所能提供的实体特征，以及对应的实体所在的位置。 • 407 Proxy Authentication Required。代理服务器要求身份验证。 这个状态码类似401（Unauthorized），但不是服务器而是代理服务器要求客户证明身份。代 理服务器必须在应答消息中包含头段Proxy-Authenticate向客户提出质询，客户可重新发送 请求消息并用头段Proxy-Authorization提供身份证明。 • 408 Request Timeout。请求超时。 客户没有在服务器预期等待的时间内发来请求消息。 • 409 Conflict。资源冲突。 客户请求的操作与资源当前的状态冲突。例如，客户请求用PUT操作更新某个资源，但这个资源在此之前已被别的客户更新过，则服务器可返回这个状态码。 • 410 Gone。资源已丢弃。 请求的资源已不在服务器上，已被永久丢弃。如果服务器不能确定资源已永久丢弃，则 应该用404（Not Found）应答。 • 411 Length Required。要求指出实体长度。 如果客户的请求消息包含实体而又没有用头段Content-Length指出实体长度，服务器可拒绝请求并且用这个状态码应答。 • 412 Precondition failed。不符合预设的条件。 客户的请求消息包含If-Modified-Since、If-None-Match、If-Range等条件，要求所操作的资源满足这些条件。服务器检查这些条件，如果有一个或多个条件不满足，服务器就用这个状 态码应答。 • 413 Request Entity Too Large。请求包含的实体太大。 请求消息包含实体，并且所包含的实体太大，服务器拒绝处理。如果服务器拒绝是由于 某种暂时的原因，则服务器应该在应答消息中包含头段Retry-After，指出过多长时间客户可以再试。 • 414 Request-URI Too Long。请求消息中的URI太长。 由于请求消息的URI太长，服务器拒绝处理。出现这种情况有两种可能：一种试客户错误 地将大量数据放在URI的部分，导致URI太长；另一种情况是黑客试图利用缓冲 区溢出的漏洞进行恶意攻击。 • 415 Unsupported Media Type。不支持的媒体类型。 客户的请求消息包含实体，对于其媒体类型，服务器无法对请求消息指定的资源进行所请 求的操作。 • 416 Requested range Not Satisfiable。不满足所请求的范围。 客户在请求消息中用头段Range指出要求获得所请求资源中的某个部分，如果所指定 的范围与资源当前的范围完全不相交，则服务器返回这个状态码。例如，请求消息用Range： bytes=1000-2000，但所请求资源的实体长度小于1000字节，则服务器返回这个状态码。服务器应该在应答消息中包含头段Content-Range，指出所请求实体当前的长度。 • 417 Expectation Failed。不能满足期望。 请求消息包含头段Expect，服务器不能满足所指出的期望。例如，当客户传送带有消息 实体的请求消息时，如果消息实体较长，而且客户不能肯定服务器是否愿意接收这个实体， 客户可先传送消息头，并且在其中包含头段Expect：100-continue，表示客户期望服务器应答状态码100并继续接受数据，服务器若不能满足期望，则用417应答。 7．5 服务器错误状态码 • 500 Internal Server Error。服务器内部错误。 服务器遇到意外情况，无法执行请求的操作。 • 501 Not Implemented。不执行的操作。 服务器不支持客户所请求的操作。 • 502 Bad Geteway。异常的网关。 代理服务器或者网关从服务器方向接收到不正常的应答消息。 • 503 Service Unavailable。暂停服务。 服务器由于负担过重或内部维护而暂停服务。服务器如果知道何时可以恢复正常工作， 则可以在应答消息中包含头段Retry-After，指出客户何时可以重试。 虽然有这个状态码，但服务器在负担过重时也可以简单地拒绝TCP连接。 • 504 Gateway Timeout。网关超时。 代理服务器或网关等待服务器的应答消息，等待时间超时。 • 505 HTTP version Not Supported。不支持的HTTP版本。 服务器不支持客户请求消息的HTTP版本。