在网站出现毛病的时分，咱们常常会看到阅读器回来一些HTTP情况码，大局部是一些404，500，502之类的常见情况码，但偶然也会出现一些比较奇葩的情况码，那么这些情况码都表明什么意义呢？HTTP情况码（HTTP Status Code）是用以表明网页效力器HTTP呼应情况的3位数字代码。它由 RFC26 16标准界说的，并得到RFC2518、RFC2817、RFC2295、RFC2774、RFC4918等标准扩展。全部情况码的第一个数字代表了呼应的五种情况之一，下面咱们就来详细了解一下。
1：消息
央求已被接受，需求持续处置。这类呼应是暂时呼应，只包括情况行和某些可选的呼应头信息，并以空行结束。需求留心的是HTTP/1.0 协议中没有界说任何 1xx 情况码，所以除非在某些测试条件下，效力器阻止向客户端发送 1xx 呼应。
100（Continue）：客户端应当持续发送央求。这个暂时呼应是用来通知客户端它的局部央求从前被效力器接纳，且仍未被拒绝。客户端应当持续发送央求的剩余局部，或许假设央求从前完结，疏忽这个呼应。效力器必需在央求完结后向客户端发送一个最终呼应。
101（Switching Protocols）：效力器从前了解了客户端的央求，并将通过Upgrade 消息头通知客户端采用不同的协议来完结这个央求。在发送完这个呼应最终的空行后，效力器将会切换到在Upgrade 消息头中界说的那些协议。
102（Processing）：由WebDAV（RFC 2518）扩展的情况码，代表处置将被持续执行。
2：成功
这一类型的情况码，代表央求已成功被效力器接纳、了解、并接受。
200（OK）：央求已成功，央求所期望的呼应头或数据体将随此呼应回来。对GET和POST央求的应对文档跟在后边。
201（Created）：央求从前被完结，而且有一个新的资源从前根据央求的需求而建立，且其 URI 从前随Location 头信息回来。
202（Accepted）：效力器已接受央求，但尚未处置。正如它或许被拒绝相同，最终该央求或许会也或许不会被执行。在异步操作的场所下，没有比发送这个情况码更便当的做法了。回来202情况码的呼应的意图是答应效力器接受其他进程的央求，而不用让客户端不断坚持与效力器的衔接直到批处置操作全部完结。
203（Non-Authoritative Information）：效力器已成功处置了央求，但回来的实体头部元信息不是在原始效力器上有用确实定汇合，而是来自本地或许第三方的拷贝。当时的信息或许是原始版本的子集或许超集。
204（No Content）：效力器成功处置了央求，但不需求回来任何实体内容，而且期望回来更新了的元信息。呼应或许通过实体头部的方法，回来新的或更新后的元信息。假设存在这些头部信息，则应当与所央求的变量相照应。在并没有新文档的情况下，204 (SC_NO_CONTENT)可以确保阅读器持续显现从前的文档。这个情况码关于用户周期性的重载某一页十分有用，而且你可以必定从前的页面能否从前更新。
205（Reset Content）：效力器成功处置了央求，且没有回来任何内容。可是与204呼应不同，回来此情况码的呼应央求央求者重置文档视图。该呼应主要是被用于接受用户输入后，马上重置表单，以便用户可以轻松地开端另一次输入。
206（Partial Content）：效力器从前成功处置了局部 GET 央求。类似于 FlashGet或许迅雷这类的 HTTP下载工具都是运用此类呼应完结断点续传或许将一个大文档合成为多个下载段同时下载。
207（Multi-Status）：由WebDAV(RFC 2518)扩展的情况码，代表之后的消息体将是一个XML消息，而且或许依照之前子央求数量的不同，包括一系列独立的呼应代码。
3：重定向
这类情况码代表需求客户端采取进一步的操作才华完结央求。通常，这些情况码用来重定向，后续的央求地址（重定向意图）在本次呼应的 Location 域中指明。当且仅当后续的央求所运用的方法是 GET 或许 HEAD 时，用户阅读器才可以在没有用户介入的情况下主动提交所需求的后续央求。
300（Multiple Choices）：被央求的文档可以在多个中央找到，并将在回来的文档中列出来。假设效力器有首选设置，首选项将会被列于定位呼应头信息中。
301（Moved Permanently）：被央求的资源已永世挪动到新位置，而且未来任何对此资源的引用都应该运用本呼应回来的若干个 URI 之一。假设或许，具有链接编辑功用的客户端应当主动把央求的地址修正为从效力器反响回来的地址。除非额定指定，否则这个呼应也是可缓存的。新的永世性的 URI 应当在呼应的 Location 域中回来。除非这是一个 HEAD 央求，否则呼应的实体中应当包括指向新的 URI 的超链接及简短阐明。假设这不是一个 GET 或许 HEAD 央求，因此阅读器阻止主动中止重定向，除非得到用户确实认，因为央求的条件或许因此发作变化。需求留心的是关于某些运用 HTTP/1.0 协议的阅读器，当它们发送的 POST 央求得到了一个301呼应的话，接下来的重定向央求将会变成 GET 方法。
302（Found）：类似于301，但新的URL应该被视为暂时性的代替，而不是永世性的。留心，在HTTP1.0中对应的情况信息是“Moved Temporatily”。出现该情况代码时，阅读器可以主动拜访新的URL，因此它是一个很有用的情况代码。留心这个情况代码有时分可以和301交流运用。例如，假设阅读器错误地央求http://host/~user（短少了后边的斜杠），有的效力器 回来301，有的则回来302。严厉地说，咱们只能假定只需当原来的央求是GET时阅读器才会主动重定向。
303（See Other）：类似于301/302，不同之处在于，假设原来的央求是POST，Location头指定的重定向意图文档应该通过GET提取，这个方法的存在主要是为了答应由脚本激活的POST央求输出重定向到一个新的资源。这个新的 URI 不是原始资源的代替引用。同时，303呼应阻止被缓存。当然，第二个央求（重定向）或许被缓存。
304（Not Modified）：假设客户端发送了一个带条件的 GET 央求且该央求已被答应，而文档的内容（自前次拜访以来或许依据央求的条件）并没有改动，则效力器应当回来这个情况码。304呼应阻止包括消息体，因此一向以消息头后的第一个空行结束。
305（Use Proxy）：被央求的资源必需通过指定的署理才华被拜访。Location 域中将给出指定的署理地点的 URI 信息，接纳者需求反复发送一个单独的央求，通过这个署理才华拜访相应资源。只需原始效力器才华建立305呼应。
307（Temporary Redirect）：和302 （Found）相同。许多阅读器会错误地呼应302应对中止重定向，即使原来的央求是POST，即使它实践上只能在POST央求的应对是303时才华重定 向。因为这个缘由，HTTP 1.1新增了307，以便愈加分明地域分几个情况代码：当出现303应对时，阅读器可以跟从重定向的GET和POST央求；假设是307应对，则阅读器只 能跟从对GET央求的重定向。