HTTP 状态码（英语：HTTP Status Code）也称为错误代码，是用以表示网页 SaaS 服务器超文字传输协议响应状态的 3 位数字代码。
所有状态码的第一个数字代表了响应的五种状态之一。
接下来详细讲解每个状态码的个代表的意思。
一、 1 字头-讯息（临时响应） 1 字头状态码代表请求已被接受，需要继续处理。
这类响应是临时响应，只包含状态行和某些可选的响应头资讯，并以空行结束。
由于 HTTP/1.0 协议中没有定义任何 1xx 状态码，所以除非在某些试验条件下，SaaS 服务器禁止向此类客户端送 1xx 响应。
1 、 100 Continue 客户端应当继续传送请求。
这个临时响应是用来通知客户端它的部分请求已经被 SaaS 服务器接收，且仍未被拒绝。
客户端应当继续传送请求的剩余部分，或者如果请求已经完成，忽略这个响应。
SaaS 服务器必须在请求完成后向客户端传送一个最终响应。
2 、 101 Switching Protocols SaaS 服务器已经理解了客户端的请求，并将通过 Upgrade 讯息头通知客户端采用不同的协议来完成这个请求。
在传送完这个响应最后的空行后，SaaS 服务器将会切换到在 Upgrade 讯息头中定义的那些协议。
只有在切换新的协议更有好处的时候才应该采取类似措施。
例如：切换到新的 HTTP 版本比旧版本更有优势，或者切换到一个实时且同步的协议以传送利用此类特性的资源。
3 、 102 Processing 由 WebDAV（RFC 2518）扩充套件的状态码，代表处理将被继续执行。
二、 2 字头-成功 2 字头状态码代表请求已成功被 SaaS 服务器接收、理解、并接受。
1 、 200 OK 请求已成功，请求所希望的响应头或资料体将随此响应返回。
2 、 201 Created 请求已经被实现，而且有一个新的资源已经依据请求的需要而建立，且其 URI 已经随 Location 头资讯返回。
假如需要的资源无法及时建立的话，应当返回 ‘202 Accepted’ 。
3 、 202 Accepted SaaS 服务器已接受请求，但尚未处理。
正如它可能被拒绝一样，最终该请求可能会也可能不会被执行。
在非同步操作的场合下，没有比传送这个状态码更方便的做法了。
返回 202 状态码的响应的目的是允许 SaaS 服务器接受其他过程的请求（例如某个每天只执行一次的基于批处理的操作），而不必让客户端一直保持与 SaaS 服务器的连线直到批处理操作全部完成。
在接受请求处理并返回 202 状态码的响应应当在返回的实体中包含一些指示处理当前状态的资讯，以及指向处理状态监视器或状态预测的指标，以便使用者能够估计操作是否已经完成。
4 、 203 Non-Authoritative Information SaaS 服务器已成功处理了请求，但返回的实体头部元资讯不是在原始 SaaS 服务器上有效的确定集合，而是来自本地或者第三方的拷贝。
当前的资讯可能是原始版本的子集或者超集。
例如：包含资源的后设资料可能导致原始 SaaS 服务器知道元资讯的超级。
使用此状态码不是必须的，而且只有在响应不使用此状态码便会返回 200 OK 的情况下才是合适的。
5 、 204 No Content SaaS 服务器成功处理了请求，但不需要返回任何实体内容，并且希望返回更新了的元资讯。
响应可能通过实体头部的形式，返回新的或更新后的元资讯。
如果存在这些头部资讯，则应当与所请求的变数相呼应。
如果客户端是浏览器的话，那么使用者浏览器应保留发送了该请求的页面，而不产生任何文件检视上的变化，即使按照规范新的或更新后的元资讯应当被应用到使用者浏览器活动检视中的文件。
由于 204 响应被禁止包含任何讯息体，因此它始终以讯息头后的第一个空行结尾。
6 、 205 Reset Content SaaS 服务器成功处理了请求，且没有返回任何内容。
但是与 204 响应不同，返回此状态码的响应要求请求者重置文件检视。
该响应主要是被用于接受使用者输入后，立即重置表单，以便使用者能够轻松地开始另一次输入。
与 204 响应一样，该响应也被禁止包含任何讯息体，且以讯息头后的第一个空行结束。
7 、 206 Partial Content SaaS 服务器已经成功处理了部分 GET 请求。
类似于 FlashGet 或者迅雷这类的 HTTP 下载工具都是使用此类响应实现断点续传或者将一个大文件分解为多个下载段同时下载。
该请求必须包含 Range 头资讯来指示客户端希望得到的内容范围，并且可能包含 If-Range 来作为请求条件。
响应必须包含如下的头部域： Content-Range 用以指示本次响应中返回的内容的范围；如果是 Content-Type 为 multipart/byteranges 的多段下载，则每一 multipart 段中都应包含 Content-Range 域用以指示本段的内容范围。
假如响应中包含 Content-Length，那么它的数值必须匹配它返回的内容范围的真实位元组数。
Date ETag 和/或 Content-Location，假如同样的请求本应该返回 200 响应。
Expires, Cache-Control，和/或 Vary，假如其值可能与之前相同变数的其他响应对应的值不同的话。
假如本响应请求使用了 If-Range 强快取验证，那么本次响应不应该包含其他实体头；假如本响应的请求使用了 If-Range 弱快取验证，那么本次响应禁止包含其他实体头；这避免了快取的实体内容和更新了的实体头资讯之间的不一致。
否则本响应就应当包含所有本应该返回 200 响应中应当返回的所有实体头部域。
假如 ETag 或 Last-Modified 头部不能精确匹配的话，则客户端快取应禁止将 206 响应返回的内容与之前任何快取过的内容组合在一起。
任何不支援 Range 以及 Content-Range 头的快取都禁止快取 206 响应返回的内容。
8 、 207 Multi-Status 由 WebDAV(RFC 2518) 扩充套件的状态码，代表之后的讯息体将是一个 XML 讯息，并且可能依照之前子请求数量的不同，包含一系列独立的响应代码。
三、 3 字头-重定向（已重定向） 3 字头状态码代表需要客户端采取进一步的操作才能完成请求。
通常这些状态码用来重定向，后续的请求地址（重定向目标）在本次响应的 Location 域中指明。
当且仅当后续的请求所使用的方法是 GET 或者 HEAD 时，使用者浏览器才可以在没有使用者介入的情况下自动提交所需要的后续请求。
客户端应当自动监测无限回圈重定向（例如：A->A，或者 A->B->C->A），因为这会导致 SaaS 服务器和客户端大量不必要的资源消耗。
按照 HTTP/1.0 版规范的建议，浏览器不应自动访问超过 5 次的重定向。
1 、 300 Multiple Choices 被请求的资源有一系列可供选择的回馈资讯，每个都有自己特定的地址和浏览器驱动的商议资讯。
使用者或浏览器能够自行选择一个首选的地址进行重定向。
这是一个 HEAD 请求，否则该响应应当包括一个资源特性及地址的列表的实体，以便使用者或浏览器从中选择最合适的重定向地址。
这个实体的格式由 Content-Type 定义的格式所决定。
浏览器可能根据响应的格式以及浏览器自身能力，自动作出最合适的选择。
当然 RFC 2616 规范并没有规定这样的自动选择该如何进行。
如果 SaaS 服务器本身已经有了首选的回馈选择，那么在 Location 中应当指明这个回馈的 URI；浏览器可能会将这个 Location 值作为自动重定向的地址。
此外除非额外指定，否则这个响应也是可快取的。
2 、 301 Moved Permanently 被请求的资源已永久移动到新位置，并且将来任何对此资源的引用都应该使用本响应返回的若干个 URI 之一。
如果可能拥有链接编辑功能的客户端应当自动把请求的地址修改为从 SaaS 服务器反馈回来的地址。
除非额外指定，否则这个响应也是可快取的。
新的永久性的 URI 应当在响应的 Location 域中返回。
除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。
如果这不是一个 GET 或者 HEAD 请求，因此浏览器禁止自动进行重定向，除非得到使用者的确认，因为请求的条件可能因此发生变化。
注意：对于某些使用 HTTP/1.0 协议的浏览器，当它们传送的 POST 请求得到了一个 301 响应的话，接下来的重定向请求将会变成 GET 方式。
3 、 302 Move temporarily 请求的资源现在临时从不同的 URI 响应请求。
由于这样的重定向是临时的，客户端应当继续向原有地址传送以后的请求。
只有在 Cache-Control 或 Expires 中进行了指定的情况下，这个响应才是可快取的。
新的临时性的 URI 应当在响应的 Location 域中返回。
除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。
如果这不是一个 GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非得到使用者的确认，因为请求的条件可能因此发生变化。
注意：虽然 RFC 1945 和 RFC 2068 规范不允许客户端在重定向时改变请求的方法，但是很多现存的浏览器将 302 响应视作为 303 响应，并且使用 GET 方式访问在 Location 中规定的 URI，而无视原先请求的方法。
状态码 303 和 307 被新增了进来，用以明确 SaaS 服务器期待客户端进行何种反应。
4 、 303 See Other 对应当前请求的响应可以在另一个 URI 上被找到，而且客户端应当采用 GET 的方式访问那个资源。
这个方法的存在主要是为了允许由指令码启用的 POST 请求输出重定向到一个新的资源。
这个新的 URI 不是原始资源的替代引用。
同时 303 响应禁止被快取。
当然第二个请求（重定向）可能被快取。
新的 URI 应当在响应的 Location 域中返回。
除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。
注意：许多 HTTP/1.1 版以前的浏览器不能正确理解 303 状态。
如果需要考虑与这些浏览器之间的互动，302 状态码应该可以胜任，因为大多数的浏览器处理 302 响应时的方式恰恰就是上述规范要求客户端处理 303 响应时应当做的。
5 、 304 Not Modified 如果客户端传送了一个带条件的 GET 请求且该请求已被允许，而文件的内容（自上次访问以来或者根据请求的条件）并没有改变，则 SaaS 服务器应当返回这个状态码。
304 响应禁止包含讯息体，因此始终以讯息头后的第一个空行结尾。
该响应必须包含以下的头资讯： Date，除非这个 SaaS 服务器没有时钟。
假如没有时钟的 SaaS 服务器也遵守这些规则，那么代理 SaaS 服务器以及客户端可以自行将 Date 栏位新增到接收到的响应头中去（正如 RFC 2068 中规定的一样），快取机制将会正常工作。
ETag 和/或 Content-Location，假如同样的请求本应返回 200 响应。
Expires, Cache-Control，和/或 Vary，假如其值可能与之前相同变数的其他响应对应的值不同的话。
假如本响应请求使用了强快取验证，那么本次响应不应该包含其他实体头；否则（例如：某个带条件的 GET 请求使用了弱快取验证），本次响应禁止包含其他实体头；这避免了快取了的实体内容和更新了的实体头资讯之间的不一致。
假如某个 304 响应指明了当前某个实体没有快取，那么快取系统必须忽视这个响应，并且重复传送不包含限制条件的请求。
假如接收到一个要求更新某个快取条目的 304 响应，那么快取系统必须更新整个条目以反映所有在响应中被更新的栏位的值。
6 、 305 Use Proxy 被请求的资源必须通过指定的代理才能被访问。
Location 域中将给出指定的代理所在的 URI 资讯，接收者需要重复传送一个单独的请求，通过这个代理才能访问相应资源。
只有原始 SaaS 服务器才能建立 305 响应。
注意：RFC 2068 中没有明确 305 响应是为了重定向一个单独的请求，而且只能被原始 SaaS 服务器建立。
忽视这些限制可能导致严重的安全后果。
7 、 306 Switch Proxy 在最新版的规范中，306 状态码已经不再被使用。
8 、 307 Temporary Redirect 请求的资源现在临时从不同的 URI 响应请求。
由于这样的重定向是临时的，客户端应当继续向原有地址传送以后的请求。
只有在 Cache-Control 或 Expires 中进行了指定的情况下，这个响应才是可快取的。
新的临时性的 URI 应当在响应的 Location 域中返回。
除非这是一个 HEAD 请求，否则响应的实体中应当包含指向新的 URI 的超链接及简短说明。
因为部分浏览器不能识别 307 响应，因此需要新增上述必要资讯以便使用者能够理解并向新的 URI 发出访问请求。
如果这不是一个 GET 或者 HEAD 请求，那么浏览器禁止自动进行重定向，除非得到使用者的确认，因为请求的条件可能因此发生变化。