这是我参与8月更文挑战的第18天,活动详情查看:8月更文挑战
主要参考《图解 HTTP》与 RFC 2616。
1XX Informational
信息性状态码:表示临时的响应,由单独的状态行和可选的响应头组成,终止于空行。本类状态码没有必须的头部。
100 Continue
:客户端应该继续它的请求。该间歇响应用于提醒客户端服务器已经接收和接受请求的开始部分。客户端应该继续发送请求的剩余部分,或者如果请求已经发送完了,就乎略该响应。服务器在请求完成后必须发送最终响应。101 Switching Protocols
:服务器理解并愿意答应客户端的请求。通过使用Upgrade
首部字段,在该连接上改变应用层协议。服务器将在101
响应的终止空行后立即切换到响应的Upgrade
首部字段中定义的协议。
2XX Success
成功状态码:表示请求正常处理完毕。
200 OK
:表示从客户端发来的请求在服务器端被正常处理了。204 No Content
:表示服务器接收的请求已成功处理,但在返回的响应报文中不含响应体。本响应禁止包含响应体,且终止于首部字段后的首个空行。一般在只需要从客户端往服务器发送信息,而对客户端不需要发送新信息内容的情况下使用。206 Partial Content
:表示服务器已经完成对局部资源的GET
请求。响应报文中包含由Content-Range
指定响应体的范围。
3XX Redirection
重定向状态码:表示浏览器需要执行附加操作以正确处理请求。
-
301 Moved Permanently
:永久重定向。表示请求的资源已被分配了新的URI
,以后应使用资源现在所指的URI
。如果已经把资源对应的URI保存为书签了,这时应该按Location
首部字段提示的URI
重新保存。 -
302 Found
:临时重定向。表示请求的资源已被分配了新的URI
,希望用户本次能使用新的URI
访问。302
状态码代表的资源不是被永久移动,只是临时性质的。换句话说,已移动的资源对应的URI
将来还有可能发生改变。用户把URI
保存成书签,不会像301
一样去更新书签。 -
303 See Other
:表示由于请求对应的资源存在着另一个URI
,应使用GET
方法定向获取请求的资源。303
状态码和302 Found
状态码有着相同的功能,但303
状态码明确表示客户端应当采用GET
方法获取资源。
当
301
、302
、303
响应状态码返回时,几乎所有的浏览器都会把POST
改成GET
,并删除请求报文内的主体,之后请求会自动再次发送。301
、302
标准是禁止将POST
方法改变成GET
方法的,但实际使用时大家都会这么做。
304 Not Modified
:表示客户端发送附带条件的请求时,服务器端允许请求访问资源,但因发生请求未满足条件的情况后,直接返回304 Not Modified
(服务器端资源未改变,可直接使用客户端未过期的缓存)。304
状态码返回时,不包含任何响应的主体部分。304
虽然被划分在3XX
类别中,但是和重定向没有关系。307 Temporary Redirect
:临时重定向。该状态码与302 Found
有着相同的含义。尽管302
标准禁止POST
变换成GET
,但实际使用时大家并不遵守。307
会遵照浏览器标准,不会从POST
变成GET
。但是,对于处理响应时的行为,每种浏览器有可能出现不同的情况。
4XX Client Error
客户端错误状态码:表示客户端是发生错误的原因所在。
400 Bad Request
:表示请求报文中存在语法错误。当错误发生时,需修改请求的内容后再次发送请求。另外,浏览器会像200 OK
一样对待该状态码。401 Unauthorized
:表示发送的请求需要有通过HTTP
认证的认证信息。另外若之前已进行过1
次请求,则表示用户认证失败。返回含有401
的响应必须包含一个适用于被请求资源的WWW-Authenticate
首部用以质询(challenge
)用户信息。当浏览器初次接收到401
响应,会弹出认证用的对话窗口。403 Forbidden
:表示服务器拒绝对请求资源的访问。404 Not Found
:表示服务器无法找到请求的资源。除此之外,也可以在服务器端拒绝请求且不想说明理由时使用。405 Method Not Allowed
:请求的方法不被允许。
5XX Server Error
服务器错误状态码:表示服务器是发生错误的原因所在。
500 Internal Server Error
服务器内部错误:表示服务器端在执行请求时发生了错误。501 Not Implemented
服务器不认识或不支持对应的请求方法。503 Service Unavailable
服务不可用:表示服务器超载或者正在停机维护,无法处理请求。如果事先得知解除以上状况需要的时间,最好写入Retry-After
首部字段再返回给客户端。