《http状态码认识》由会员分享，可在线阅读，更多相关《http状态码认识（12页珍藏版）》请在金锄头文库上搜索。
1、 Content-type HTML 转义字符 RGB 颜色参考 ASCII 比照表 状态码详解 运算符优先级 TCP/UDP 常见端口参考 网页字体参考状态码含义客户端应当连续发送恳求。这个临时响应是用来通知客户端它的局部恳求已经被效劳100 器接收，且仍未被拒绝。客户端应当连续发送恳求的剩余局部，或者假设恳求已经完 成，无视这个响应。效劳器必需在恳求完成后向客户端发送一个最终响应。效劳器已经理解了客户端的恳求，并将通过 Upgrade 消息头通知客户端承受不同的协议来完成这个恳求。在发送完这个响应最终的空行后，效劳器将会切换到在 Upgrade101 消息头中定义的那些协议。只有在切换新的
2、协议更有好处的时候才应当实行类似措施。例如，切换到新的 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。102由WebDAVRFC 2518扩展的状态码，代表处理将被连续执行。200恳求已成功，恳求所期望的响应头或数据体将随此响应返回。恳求已经被实现，而且有一个新的资源已经依据恳求的需要而建立，且其 URI 已经201随 Location 头信息返回。假设需要的资源无法准时建立的话，应当返回 ”202Accepted”。效劳器已承受恳求，但尚未处理。正如它可能被拒绝一样，最终该恳求可能会也可能 不会被执行。在异步操作的场合下，没有比发送这个状态码更便利的做法了。
3、返回 202 状态码的响应的目的是允许效劳器承受其他过程的恳求例如某个每天只执行202 一次的基于批处理的操作，而不必让客户端始终保持与效劳器的连接直到批处理操作全部完成。在承受恳求处理并返回 202 状态码的响应应当在返回的实体中包含一些指示处理当前状态的信息，以及指向处理状态监视器或状态推测的指针，以便用户能够估量操作是否已经完成。效劳器已成功处理了恳求，但返回的实体头部元信息不是在原始效劳器上有效确实定集合，而是来自本地或者第三方的拷贝。当前的信息可能是原始版本的子集或者超集。203例如，包含资源的元数据可能导致原始效劳器知道元信息的超级。使用此状态码不是 必需的，而且只有在响应不使用此
4、状态码便会返回 200 OK 的状况下才是适宜的。效劳器成功处理了恳求，但不需要返回任何实体内容，并且期望返回更新了的元信息。响应可能通过实体头部的形式，返回新的或更新后的元信息。假设存在这些头部信息， 那么应当与所恳求的变量相照应。假设客户端是扫瞄器的话，那么用户扫瞄器应保204留发送了该恳求的页面，而不产生任何文档视图上的变化，即使依据标准新的或更新后的元信息应当被应用到用户扫瞄器活动视图中的文档。由于 204 响应被制止包含任何消息体，因此它始终以消息头后的第一个空行结尾。效劳器成功处理了恳求，且没有返回任何内容。但是与 204 响应不同，返回此状态码的响应要求恳求者重置文档视图。该响应
5、主要是被用于承受用户输入后，马上重置表205单，以便用户能够轻松地开头另一次输入。与 204 响应一样，该响应也被制止包含任何消息体，且以消息头后的第一个空行完毕。效劳器已经成功处理了局部 GET 恳求。类似于 FlashGet 或者迅雷这类的 下载工具都是使用此类响应实现断点续传或者将一个大文档分解为多个下载段同时下 载。该恳求必需包含 Range 头信息来指示客户端期望得到的内容范围，并且可能包含 If-Range 来作为恳求条件。响应必需包含如下的头部域：Content-Range 用以指示本次响应中返回的内容的范围；假设是 Content-Type 为multipart/byteran
6、ges 的多段下载，那么每一 multipart 段中都应包含 Content-Range 域用以指示本段的内容范围。假设响应中包含 Content-Length，那么它的数值必需匹配它返回的内容范围的真实字节数。 Date ETag 和/或 Content-Location，206 假设同样的恳求本应当返回 200 响应。 Expires, Cache-Control，和/或 Vary，假设其值可能与之前一样变量的其他响应对应的值不同的话。 假设本响应恳求使用了 If-Range 强缓存验证，那么本次响应不应当包含其他实体头；假设本响应的恳求使用了 If-Range 弱缓存验证，那么本次响应
7、制止包含其他实体头；这避开了缓存的实体内容和更新了的实体头信息之间的不全都。否那么，本响应就应当包含全部本应当返回 200 响应中应当返回的全部实体头部域。 假设 ETag 或 Last-Modified 头部不能准确匹配的话，那么客户端缓存应制止将 206 响应返回的内容与之前任何缓存过的内容组合在一起。 任何不支持 Range 以及 Content-Range 头的缓存都制止缓存 206 响应返回的内容。由WebDAV(RFC 2518)扩展的状态码，代表之后的消息体将是一个 XML 消息，并且207可能依照之前子恳求数量的不同，包含一系列独立的响应代码。被恳求的资源有一系列可供选择的回馈
8、信息，每个都有自己特定的地址和扫瞄器驱动300 的协商信息。用户或扫瞄器能够自行选择一个首选的地址进展重定向。 除非这是一个 HEAD 恳求，否那么该响应应当包括一个资源特性及地址的列表的实体，以便用户或扫瞄器从中选择最适宜的重定向地址。这个实体的格式由 Content-Type 定义的格式所打算。扫瞄器可能依据响应的格式以及扫瞄器自身力量，自动作出最适宜的选择。固然，RFC 2616 标准并没有规定这样的自动选择该如何进展。假设效劳器本身已经有了首选的回馈选择，那么在 Location 中应当指明这个回馈的 URI；扫瞄器可能会将这个 Location 值作为自动重定向的地址。此外，除非额外
9、指定，否那么这个响应也是可缓存的。被恳求的资源已永久移动到新位置，并且将来任何对此资源的引用都应当使用本响应返回的假设干个 URI 之一。假设可能，拥有链接编辑功能的客户端应当自动把恳求的地址修改为从效劳器反响回来的地址。除非额外指定，否那么这个响应也是可缓存的。新的永久性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 恳求，301 否那么响应的实体中应当包含指向新的 URI 的超链接及简短说明。假设这不是一个 GET 或者 HEAD 恳求，因此扫瞄器制止自动进展重定向，除非得到用户确实认， 由于恳求的条件可能因此发生变化。留意：对于某些使用 /1.0 协议的扫瞄
10、器，当它们发送的 POST 恳求得到了一个 301 响应的话，接下来的重定向恳求将会变成 GET 方式。恳求的资源现在临时从不同的 URI 响应恳求。由于这样的重定向是临时的，客户端应当连续向原有地址发送以后的恳求。只有在 Cache-Control 或 Expires 中进展了指定的状况下，这个响应才是可缓存的。 新的临时性的 URI 应当在响应的 Location 域中返回。除非这是一个 HEAD 恳求，否那么响应的实体中应当包含指向新的 URI 的302 超链接及简短说明。 假设这不是一个 GET 或者 HEAD 恳求，那么扫瞄器制止自动进展重定向，除非得到用户确实认，由于恳求的条件可能
11、因此发生变化。 留意：虽然RFC 1945 和 RFC 2068 标准不允许客户端在重定向时转变恳求的方法，但是很多现存的扫瞄器将 302 响应视作为 303 响应，并且使用 GET 方式访问在Location 中规定的 URI，而无视原先恳求的方法。状态码 303 和 307 被添加了进来，用以明确效劳器期盼客户端进展何种反响。对应当前恳求的响应可以在另一个 URI 上被找到，而且客户端应当承受 GET 的方式访问那个资源。这个方法的存在主要是为了允许由脚本激活的 POST 恳求输出重定向到一个新的资源。这个新的 URI 不是原始资源的替代引用。同时，303 响应制止被缓存。固然，其次个恳求
12、重定向可能被缓存。新的 URI 应当在响应的303 Location 域中返回。除非这是一个 HEAD 恳求，否那么响应的实体中应当包含指向新的 URI 的超链接及简短说明。 留意：很多 /1.1 版以前的 扫瞄器不能正确理解 303 状态。假设需要考虑与这些扫瞄器之间的互动， 302 状态码应当可以胜任， 由于大多数的扫瞄器处理 302 响应时的方式恰恰就是上述标准要求客户端处理 303 响应时应当做的。假设客户端发送了一个带条件的 GET 恳求且该恳求已被允许，而文档的内容自上次访问以来或者依据恳求的条件并没有转变，那么效劳器应当返回这个状态码。304 响应制止包含消息体，因此始终以消息头
13、后的第一个空行结尾。 该响应必需包含以下的头信息： Date，除非这个效劳器没有时钟。假设没有时钟的效劳器也遵守这些规章，那么代理效劳器以及客户端可以自行将 Date 字段添加到接收到的响应头中去正如 RFC 2068 中规定的一样，缓存机制将会正常工作。ETag 和/或304 Content-Location，假设同样的恳求本应返回 200 响应。Expires, Cache-Control， 和/或 Vary，假设其值可能与之前一样变量的其他响应对应的值不同的话。假设本响应恳求使用了强缓存验证，那么本次响应不应当包含其他实体头；否那么例如， 某个带条件的 GET 恳求使用了弱缓存验证，本次
14、响应制止包含其他实体头；这避开了缓存了的实体内容和更新了的实体头信息之间的不全都。假设某个 304 响应指明白当前某个实体没有缓存，那么缓存系统必需无视这个响应，并且重复发送不包含限制条件的恳求。假设接收到一个要求更新某个缓存条目的 304 响应，那么缓存系统必需更新整个条目以反映全部在响应中被更新的字段的值。被恳求的资源必需通过指定的代理才能被访问。Location 域中将给出指定的代理所在的 URI 信息，接收者需要重复发送一个单独的恳求，通过这个代理才能访问相应资305 源。只有原始效劳器才能建立 305 响应。留意：RFC 2068 中没有明确 305 响应是为了重定向一个单独的恳求，
15、而且只能被原始效劳器建立。无视这些限制可能导致严峻的平安后果。306 在最新版的标准中，306 状态码已经不再被使用。恳求的资源现在临时从不同的 URI 响应恳求。由于这样的重定向是临时的，客户端应当连续向原有地址发送以后的恳求。只有在 Cache-Control 或 Expires 中进展了指定的状况下，这个响应才是可缓存的。 新的临时性的 URI 应当在响应的 Location307400域中返回。除非这是一个 HEAD 恳求，否那么响应的实体中应当包含指向新的 URI 的超链接及简短说明。由于局部扫瞄器不能识别 307 响应，因此需要添加上述必要信息以便用户能够理解并向新的 URI 发出访问恳求。假设这不是一个 GET 或者HEAD 恳求，那么扫瞄器制止自动进展重定向，除非得到用户确实认，由于恳求的条件可能因此发生变化。1、语义有误，当前恳求无法被效劳器理解。除非进展修改，否那么客户端不应当重复 提交这个恳求。2、恳求参数有误。当前恳求需要用户
