《HTTP 1.1状态代码及其含义》由会员分享，可在线阅读，更多相关《HTTP 1.1状态代码及其含义（5页珍藏版）》请在金锄头文库上搜索。
1、 1.1 状态代码及其含义下表显示了常见的 1.1 状态代码以及它们对应的状态信息和含义。应当慎重地使 用那些只有 1.1 支持的状态代码,由于很多扫瞄器还只能够支持 1.0。假设你使 用 了 1.1 特 有 的 状 态 代 码 , 最 好 能 够 检 查 一 下请 求 的 版 本 号 (通 过 ServletRequest 的 getProtocol 方法 。代码 状态信息 含义100 Continue 初始的恳求已经承受,客户应当连续发送恳求的其余局部。 ( 1.1 新 101 Switching Protocols 效劳器将遵从客户的恳求转换到另外一种协议( 1.1 新 200 OK 一
2、切正常,对 GET 和 POST 恳求的应答文档跟在后面。假设不用setStatus 设置状 态代码, Servlet 默认使用 202 状态代码。201 Created 效劳器已经创立了文档, Location 头给出了它的 URL 。202 Accepted 已经承受恳求,但处理尚未完成。203 Non-Authoritative Information 文档已经正常地返回,但一些应答头可能不正确,由于 使用的是文档的拷贝( 1.1 新 。204 No Content 没有新文档, 扫瞄器应当连续显示原来的文档。 假设用户定期地刷新页面, 而 Servlet 可以确定用户文档足够新,这个状
3、态代码是很有用的。205 Reset Content 没有新的内容,但扫瞄器应当重置它所显示的内容。用来强制扫瞄器清 除表单输入内容( 1.1 新 。206 Partial Content 客户发送了一个带有 Range 头的 GET 恳求, 效劳器完成了它 ( 1.1 新 。300 Multiple Choices 客户恳求的文档可以在多个位置找到,这些位置已经在返回的文档内 列出。假设效劳器要提出优先选择,那么应当在 Location 应答头指明。301 Moved Permanently 客户恳求的文档在其他地方,新的 URL 在 Location 头中给出,浏 览器应当自动地访问新的
4、URL 。302 Found 类似于 301,但新的 URL 应当被视为临时性的替代,而不是永久性的。留意, 在 1.0 中对应的状态信息是 “Moved Temporatily”而 , ServletResponse 中相应的常量 是 SC_MOVED_TEMPORARILY ,而不是SC_FOUND。消灭该状态代码时,扫瞄器能够自动访问新的 URL ,因此它是一个很有用的状态代码。为 此, Servlet 供给了一个专用的方法,即 sendRedirect 。使用response.sendRedirect (url 比使 用 response.setStatus (response.SC_
5、MOVED_TEMPORARILY 和 response.setHeader (“Location“,url 更好。这是由于:首先,代码更加简洁。其次,使用 sendRedirect , Servlet 会自动构造一个包含新链接的页面(用于那些不能自动重 定向的老式扫瞄器 。最终, sendRedirect 能够处理相对 URL ,自动把它们转换成确定 URL 。留意这个状态代码有时候可以和 301 替换使用。 例如, 假设扫瞄器错误地恳求 :/host/user (缺少了后面的斜杠 ,有的效劳器返回 301,有的那么返回 302。严格地说,我们只能假定只有当原来的恳求是 GET 时扫瞄器才会
6、自动重定向。请参见 307。 303 See Other 类似于 301/302,不同之处在于,假设原来的恳求是 POST , Location 头指定 的重定向目标文档应当通过 GET 提取( 1.1 新 。304 Not Modified 客 户 端 有 缓 冲 的 文 档 并 发 出 了 一 个 条 件 性 的 请 求(一 般 是 提 供 If-Modified-Since 头表示客户只想比指定日期更新的文档 。 效劳器告知客户, 原来缓冲的文 档还可以连续使用。305 Use Proxy 客户恳求的文档应当通过 Location 头所指明的代理效劳器提取( 1.1 新 。307 Tem
7、porary Redirect 和 302(Found 一样 。 很多扫瞄器会错误地响应 302 应答进展重定 向, 即使原来的恳求是 POST , 即使它实际上只能在 POST 恳求的应答是 303 时才能重定向。 由于这个缘由, 1.1 新增了 307, 以便更加去除地区分几个状态代码:当消灭 303 应答 时,扫瞄器可以跟随重定向的 GET 和 POST 恳求;假设是 307 应答,那么扫瞄器只能跟随对 GET 恳求的重定向。留意, ServletResponse 中没有为该状态代码供给相应的常量。 ( 1.1 新400 Bad Request 恳求消灭语法错误。401 Unauthor
8、ized 客 户 试 图 未 经 授 权 访 问 受 密 码 保 护 的 页 面 。 应 答中 会 包 含 一 个 WWW-Authenticate 头,浏 览 器据 此 显示 用 户名字 /密 码 对 话框 ,然 后 在填 写 适宜 的 Authorization 头后再次发出恳求。403 Forbidden 资源不行用。效劳器理解客户的恳求,但拒绝处理它。通常由于效劳器上 文件或名目的权限设置导致。404 Not Found 无法找到指定位置的资源。这也是一个常用的应答, ServletResponse 专 门供给了相应的方法:sendError (message 。405 Method
9、Not Allowed 恳求方法(GET 、 POST 、 HEAD 、 DELETE 、PUT 、 TRACE 等 对指定的资源不适用。 ( 1.1 新406 Not Acceptable 指定的资源已经找到,但它的 MIME 类型和客户在 Accpet头中所指定 的不兼容( 1.1 新 。407 Proxy Authentication Required 类似于 401,表示客户必需先经过代理效劳器的授权。 ( 1.1 新408 Request Timeout 在效劳器许可的等待时间内,客户始终没有发出任何恳求。客户可以 在以后重复同一恳求。 ( 1.1 新409 Conflict 通常和
10、 PUT 恳求有关。 由于恳求和资源的当前状态相冲突, 因此恳求不能成功。 ( 1.1 新410 Gone 所恳求的文档已经不再可用, 而且效劳器不知道应当重定向到哪一个地址。 它和 404 的不同在于,返回 407 表示文档永久地离开了指定的位置,而 404 表示由于未知的缘由 文档不行用。 ( 1.1 新411 Length Required 效劳器不能处理恳求, 除非客户发送一个 Content-Length头。 ( 1.1 新412 Precondition Failed 恳求头中指定的一些前提条件失败( 1.1 新 。413 Request Entity Too Large 目标文档
11、的大小超过效劳器当前情愿处理的大小。 假设效劳器 认为自己能够稍后再处理该恳求,那么应当供给一个 Retry-After 头( 1.1 新 。414 URI Too Long URI 太长( 1.1 新 。416 Requested Range Not Satisfiable 效劳器不能满足客户在恳求中指定的 Range头。 ( 1.1 新500 Internal Server Error 效劳器遇到了意料不到的状况,不能完成客户的恳求。501 Not Implemented 效劳器不支持实现恳求所需要的功能。例如,客户发出了一个效劳器 不支持的 PUT 恳求。502 Gateway 效劳器作为网关或者代理时, 为了完成恳求访问下一个效劳器, 但该效劳器返回了非法的应答。503 Service Unavailable 效劳器由于维护或者负载过重未能应答。例如, Servlet 可能在数据 库连接池已满的状况下返回 503。效劳器返回 503 时可以供给一个Retry-After 头。504 Gateway Timeout 由作为代理或网关的效劳器使用, 表示不能准时地从远程效劳器获得 应答。 ( 1.1 新505 Version Not Supported 效劳器不支持恳求中所指明的 版本。( 1.1 新
