老忘记这些，就把它给摘了下来 6.1 状态行 （Status-Line）响应消息的第一行是状态行（stauts-Line），由协议版本以及数字状态码和相关的文本短语组成,各部分间用空格符隔开，除了最后的回车或换行外，中间不允许有回车换行． Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF 6.1.1状态码与原因短语 （Status Code and Reason Phrase）状态码是试图理解和满足请求的三位数字的整数码，这些码的完整定义在第十章。原因短语（Reason-Phrase）是为了给出的关于状态码的文本描述。状态码用于控制条件，而原因短语（Reason-Phrase）是让用户便于阅读。客户端不需要检查和显示原因短语。 状态码的第一位数字定义响应类型。后两位数字没有任何分类角色。第一位数字有五种值： -1xx: 报告的 - 接收到请求，继续进程. -2xx 成功 - 步骤成功接收，被理解，并被接受 -3xx 重发 - 为了完成请求,必须采取进一步措施. -4xx 客户端出错 - 请求包括错的顺序或不能完成. -5xx 服务器出错 - 服务器无法完成显然有效的请求. 下面列举了为HTTP/1.1定义的态码值，和对应的原因短语（Reason-Phrase）的例子。原因短语在这里例举只是建议性的----它们也许被一个局部的等价体代替而不会影响此协议的语义。 Status-Code ＝ "100" ; 10.1.1节: 继续 |"101" ; 10.1.2节: 转换协议 |"200" ; 10.2.1节: OK |"201" ; 10.2.2节: 创建 |"202" ; 10.2.3节: 接受 |"203" ; 10.2.4节: 非权威信息 |"204" ; 10.2.5节: 无内容 |"205" ; 10.2.6节: 重置内容 |"206" ; 10.2.7节: 局部内容 |"300" ; 10.3.1节: 多样选择 |"301" ; 10.3.2节: 永久移动 |"302" ; 10.3.3节: 创建 |"303" ; 10.3.4节: 观察别的部分 |"304" ; 10.3.5节: 只读 |"305" ; 10.3.6节: 用户代理 |"307" ; 10.3.8节 临时重发 |"400" ; 10.4.1节: 坏请求 |"401" ; 10.4.2节: 未授权的 |"402" ; 10.4.3节: 必要的支付 |"403" ; 10.4.4节: 禁用 |"404" ; 10.4.5节: 没找到 |"405" ; 10.4.6节: 不允许的方式 |"406" ; 10.4.7节: 不接受 |"407" ; 10.4.8节: 需要代理验证 |"408" ; 10.4.9节： 请求超时 |"409" ; 10.4.10节； 冲突 |"410" ; 10.4.11节： 停止 |"411" ; 10.4.12节： 需要的长度 |"412" ； 10.4.13节； 预处理失败 |"413" ; 10.4.14节： 请求实体太大 |"414" ; 10.4.15节； 请求-URI太大 |"415" ; 10.4.16节： 不支持的媒体类型 |"416" ； 10.4.17节： 请求的范围不满足 |"417" ; 10.4.18节： 期望失败 |"500" ; 10.5.1节: 服务器内部错误 |"501" ; 10.5.2节: 不能实现 |"502" ; 10.5.3节: 坏网关 |"503" ; 10.5.4节: 服务不能实现 |"504" ; 10.5.5节: 网关超时 |"505" ; 10.5.6节: HTTP版本不支持 |扩展码 extension-code =3DIGIT Reason-Phrase = *<TEXT,excluding CR,LF> HTTP状态码是可扩展的。HTTP应用程序不需要理解所有已注册状态码的含义，尽管那样的理解显而易见是很合算的。但是，应用程序必须了解由第一位数字指定的状态码的类型，任何未被识别的响应应被看作是该类型的x00状态，有一个例外就是未被识别的响应不能缓存。例如，如果客户端收到一个未被识别的状态码431，则可以安全的假定请求有错，并且它会对待此响应就像它接收了一个状态码是400的响应。在这种情况下，用户代理（user agent）应当把实体和响应一起提交给用户，因为实体很可能包括人可读的关于解释不正常状态的信息。
评论