常见HTTP状态码
本文主要介绍了 HTTP 状态码的作用和分类。HTTP 状态码是 Web Server 用来告诉客户端当前的网页请求发生了什么事,或者是当前 Web 服务器的响应状态,常用来判断和分析当前 Web 服务器的运行状况。状态码位于 HTTP Response 的第一行中,包括一个三位数字的状态码和一个状态消息。根据状态码的不同,可以将其分为五类:信息性、成功、重定向、客户端错误和服务器错误。其中,信息性代表请求已被接受,需要继续处理;成功代表请求已成功被服务器接收、理解、并接受;重定向代表需要客户端采取进一步的操作才能完成请求;客户端错误代表客户端看起来可能发生了错误,妨碍了服务器的处理;服务器错误代表服务器无法完成明显有效的请求。常见的状态码包括200、301、302、404、500等。了解 HTTP 状态码的分类和含义对于 Web 开发和运维人员具有重要意义。
常见HTTP状态码
HTTP 状态码(HTTP Status Code)是用以表示网页服务器超文本传输协议响应状态的 3 位数字代码。它由 RFC 2616 规范定义的,并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 与 RFC 4918 等规范扩展。所有状态码的第一个数字代表了响应的五种状态之一。所示的消息短语是典型的,但是可以提供任何可读取的替代方案。除非另有说明,状态码是HTTP / 1.1标准(RFC 7231)的一部分。
状态码的作用
HTTP 状态码的核心作用是 Web Server 用来告诉客户端,当前的网页请求发生了什么事,或者是当前 Web 服务器的响应状态。所以HTTP 状态码常用来判断和分析当前 Web 服务器的运行状况。
状态码位于 HTTP Response 的第一行中,会返回一个"三位数字的状态码"和一个"状态消息"。"三位数字的状态码"便于程序进行处理, "状态消息"便于人理解。
HTTP 状态码分类
状态码 | 响应类别 | 原因短语 |
---|---|---|
1XX | 消息(Informational) | 请求已被服务器接收,继续处理 |
2XX | 成功(Success) | 请求已成功被服务器接收、理解、并接受 |
3XX | 重定向(Redirection) | 需要后续操作才能完成这一请求 |
4XX | 请求错误(Client Error) | 请求含有词法错误或者无法被执行 |
5XX | 服务器错误(Server Error) | 服务器在处理某个正确请求时发生错误 |
常见状态码
1XX 信息性
这一类型的状态码,代表请求已被接受,需要继续处理。这类响应是临时响应,只包含状态行和某些可选的响应头信息,并以空行结束。由于 HTTP/1.0 协议中没有定义任何 1xx 状态码,所以除非在某些试验条件下,服务器禁止向此类客户端发送 1xx 响应。这些状态码代表的响应都是信息性的,标示客户应该采取的其他行动。
100 Continue
这个临时响应是用来通知客户端它的请求头已经被服务器接收,且仍未被拒绝。客户端应当继续发送请求主体,或者如果请求已经完成,忽略这个响应。服务器必须在请求完成后向客户端发送一个最终响应。
101 Switching Protocols
服务器已经理解了客户端的请求,并将通过 Upgrade 消息头通知客户端采用不同的协议来完成这个请求。在发送完这个响应最后的空行后,服务器将会切换到在 Upgrade 消息头中定义的那些协议。
只有在切换新的协议更有好处的时候才应该采取类似措施。例如,切换到新的 HTTP 版本比旧版本更有优势,或者切换到一个实时且同步的协议(如WebSocket)以传送利用此类特性的资源。
102 Processing
WebDAV 请求可能包含许多涉及文件操作的子请求,需要很长时间才能完成请求。该代码表示服务器已经收到并正在处理请求,但无响应可用。这样可以防止客户端超时,并假设请求丢失。
2XX 成功
这一类型的状态码,代表请求已成功被服务器接收、理解、并接受。
200 OK
请求已成功,请求所希望的响应头或数据体将随此响应返回。实际的响应将取决于所使用的请求方法。在 GET 请求中,响应将包含与请求的资源相对应的实体。在 POST 请求中,响应将包含描述或操作结果的实体。
204 No Content
服务器成功处理了请求,没有返回任何内容。
浏览器向服务器发送请求后收到了 204,那么浏览器页面不会发生更新,一般用在只是客户端向服务器发送信息,而服务器不用向客户端返回什么信息的情况。
206 Partial Content
服务器已经成功处理了部分 GET 请求。类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下载。
3XX 重定向
这类状态码代表需要客户端采取进一步的操作才能完成请求。通常,这些状态码用来重定向,后续的请求地址(重定向目标)在本次响应的 Location 域中指明。
301 Moved Permanently
永久重定向,表示请求的资源已经永久的搬到了其他位置。
就是说资源已经被分配了新的 URI,新的永久性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求,否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。
302 Found
临时重定向,表示请求的资源临时搬到了其他位置。
请求的资源暂时被配到到了新的 URI 和301很像,只不过资源是临时移动,资源在将来可能还会改变;同样地,新的临时性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 请求,否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。
303 See Other
表示请求资源存在另一个 URI,应使用 GET 定向获取请求资源。
303 功能与 302 一样,区别只是 303 明确客户端应该使用 GET访问。
注意:许多HTTP/1.1版以前的浏览器不能正确理解303状态。如果需要考虑与这些浏览器之间的互动,302状态码应该可以胜任,因为大多数的浏览器处理302响应时的方式恰恰就是上述规范要求客户端处理303响应时应当做的。
304 Not Modified
表示资源在由请求头中的 If-Modified-Since 或 If-None-Match 参数指定的这一版本之后,未曾被修改。在这种情况下,由于客户端仍然具有以前下载的副本,因此不需要重新传输资源。虽然 304 被划分在 3XX,但和重定向并没有关系。
307 Temporary Redirect
临时重定向,和 302 有着相同含义。
尽管 302 标准禁止 POST 变为 GET,但没人听他的,而 307 就会遵照标准,不会从 POST 变为 GET,但处理响应行为,各个浏览器可能不同。
4XX 客户端错误
这类的状态码代表了客户端看起来可能发生了错误,妨碍了服务器的处理。除非响应的是一个 HEAD 请求,否则服务器就应该返回一个解释当前错误状况的实体,以及这是临时的还是永久性的状况。这些状态码适用于任何请求方法。浏览器应当向用户显示任何包含在此类错误响应中的实体内容。
400 Bad Request
由于明显的客户端错误(例如,格式错误的请求语法,太大的大小,无效的请求消息或欺骗性路由请求),服务器不能或不会处理该请求。
401 Unauthorized
该状态码表示当前请求需要用户验证。该响应必须包含一个适用于被请求资源的 WWW-Authenticate 信息头用以询问用户信息。客户端可以重复提交一个包含恰当的 Authorization 头信息的请求。如果当前请求已经包含了 Authorization 证书,那么 401 响应代表着服务器验证已经拒绝了那些证书。如果 401 响应包含了与前一个响应相同的身份验证询问,且浏览器已经至少尝试了一次验证,那么浏览器应当向用户展示响应中包含的实体信息,因为这个实体信息中可能包含了相关诊断信息。
注意:当网站(通常是网站域名)禁止IP地址时,有些网站状态码显示的 401,表示该特定地址被拒绝访问网站。
403 Forbidden
服务器已经理解请求,但是拒绝执行它。与 401 响应不同的是,身份验证并不能提供任何帮助,而且这个请求也不应该被重复提交。如果这不是一个 HEAD 请求,而且服务器希望能够讲清楚为何请求不能被执行,那么就应该在实体内描述拒绝的原因。当然服务器也可以返回一个 404 响应,假如它不希望让客户端获得任何信息。
404 Not Found
请求失败,请求所希望得到的资源未被在服务器上发现,但允许用户的后续请求。没有信息能够告诉用户这个状况到底是暂时的还是永久的。404 这个状态码被广泛应用于当服务器不想揭示到底为何请求被拒绝或者没有其他适合的响应可用的情况下。
5XX 服务器错误
表示服务器无法完成明显有效的请求。这类状态码代表了服务器在处理请求的过程中有错误或者异常状态发生,也有可能是服务器意识到以当前的软硬件资源无法完成对请求的处理。除非这是一个 HEAD 请求,否则服务器应当包含一个解释当前错误状态以及这个状况是临时的还是永久的解释信息实体。浏览器应当向用户展示任何在当前响应中被包含的实体。这些状态码适用于任何响应方法。
500 Internal Server Error
通用错误消息,服务器遇到了一个未曾预料的状况,导致了它无法完成对请求的处理。没有给出具体错误信息。可能是 Web 应用有 bug 或临时故障,更有可能是服务器源代码有 bug。
503 Service Unavailable
由于临时的服务器维护或者过载,服务器当前无法处理请求。这个状况是暂时的,并且将在一段时间以后恢复。如果能够预计延迟时间,那么响应中可以包含一个 Retry-After 头用以标明这个延迟时间。如果没有给出这个 Retry-After 信息,那么客户端应当以处理 500 响应的方式处理它。