HTTP的状态码有很多种,主要有1xx（临时响应）、2xx（成功）、3xx（已重定向）、4xx（请求错误）以及5xx（服务器错误）五个大类，每个大类还对应一些具体的分类。平时我们接触比较多的是200、400、500等。

这里我们主要讨论一下状态码204，在HTTP RFC 2616中关于204的描述如下:

If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent’s active view.

意思等同于请求执行成功，但是没有数据，浏览器不用刷新页面.也不用导向新的页面。如何理解这段话呢。还是通过例子来说明吧，假设页面上有个form，提交的url为http-204.htm，提交form，正常情况下，页面会跳转到http-204.htm，但是如果http-204.htm的相应的状态码是204，此时页面就不会发生转跳，还是停留在当前页面。另外对于a标签，如果链接的页面响应码为204，页面也不会发生跳转。

所以对于一些提交到服务器处理的数据，只需要返回是否成功的情况下，可以考虑使用状态码204（也就是XMLHttpRequest.status）来作为返回信息，从而省掉多余的数据传输。

$.ajax({
            type: "POST",
            beforeSend: function(xhr){xhr.setRequestHeader('__RequestVerificationAntiCSRFToken', $("#hidden-CSRFToken").val());},
            url: $(this).data('targetUrl'),
            cache: false,
            data:post_data,
            dataType:"json",
            async: true,
            error: function(jqXHR, error, errorThrown) {
                alert(jqXHR.status);
                },
            success: function(data) {
               //...
               }
  });

上次我们讲了HTTP/304响应,今天我们继续讨论另外三种可能让Fiddler用户感到困惑的请求或响应类型.

下面的截图中有三条Web会话,每一条都返回了不同的状态码,但都在HTTP/2xx范围内:

HEAD请求方法

第一个请求返回了HTTP/200,但你应该注意到了,服务器并没有返回响应体.如果你在Inspectors选项卡中查看一下,就会发现客户端使用的是HEAD请求方法.HEAD方法允许客户端仅向服务器请求某个资源的响应头,而不要真正的下载该资源本身.服务器返回的响应头应该和客户端使用GET方法请求该资源时返回的请求头相同,比起GET方法,只是省略了响应体.

从上图中可以看出,如果客户端使用GET而不是HEAD方法请求该资源,服务器就应该会返回6623字节大小的响应体.还可以看出,该资源的类型为text/html以及它的编码为UTF-8.客户端可以使用HEAD请求来收集相关信息以确定如何操作该资源.例如,在IE中,如果一个OBJECT元素缺少TYPE参数,浏览器就会发送一个HEAD请求,目标URL为这个OBJECT元素的SRC属性指定的URL.然后浏览器就能够根据响应中的Content-Type头知道这是哪种类型的OBJECT.

HTTP/204响应

会话列表中的第二条会话返回了HTTP/204响应.从Content-Length响应头可以看出,该响应没有响应体,状态码描述为“No Content”:

你也许会有疑问:“返回一个没有响应体的HTTP/200响应不行吗?”

如果没有响应体,则在大多数场景下,这两种响应码完全等效,但有一种情况下,HTTP/204响应会让浏览器有不同的表现.这种情况就是当用户在浏览器窗口window或者frame/iframe框架中导航的时候.

• 如果导航到的URL返回了一个没有响应体的HTTP/200响应,则页面将会显示一个空白文档(就是一片白色).页面的URL地址也会变成新指定的URL.
• 如果服务器返回的是一个HTTP/204响应,当前页面不会有任何变化,就好像根本没有进行导航操作一样.页面的URL地址也保持不变.

HTTP/205响应码很少见,它类似于HTTP/204,除了页面保留在当前文档不变以外,多了一步操作,就是要清空当前文档内所有表单控件的内容.

HTTP/206响应

最后一条会话返回了HTTP/206 “Partial Content”响应.这种响应是在客户端表明自己只需要目标URL上的部分资源的时候返回的.这种情况经常发生在客户端继续请求一个未完成的下载的时候(通常是当客户端加载一个体积较大的嵌入文件,比如视屏或PDF文件),或者是客户端尝试实现带宽遏流的时候.

你可以通过Range请求头辨认出一个部分内容请求.该请求头表明了客户端需要请求资源的哪一部分:

在上图的请求中,客户端告诉服务器,它需要该视屏文件中从172,032到13,325,503字节范围内的数据.

在大多数情况下,客户端还会发送一些条件请求头,让服务器来辨别该返回哪个版本的资源.在上图的请求中,客户端把它在上次接收该资源的0到172032字节部分请求中服务器返回的ETag响应头作为了本次请求的If-Match请求头发送了出去,同样还把上次响应中的Last-Modified响应头用If-Unmodified-Since请求头发送了出去.

如果服务器发现该资源的版本与客户端所请求的版本不匹配,则会返回一个HTTP/412 Precondition Failed响应.如果客户端使用If-Range请求头而不是If-Match发送了上次收到的ETag响应头的值,且服务器发现客户端请求的版本与当前资源的版本不匹配,则服务器会返回整个资源数据.如果客户端需要完整的资源数据,使用If-Range可以减少一个网络请求.

服务器的Content-Range响应头表明了返回的是文件的哪一部分,Content-Length响应头表明了该部分文件的大小:

你也许注意到了Accept-Ranges响应头,服务器发送这个头的目的是让客户端知道服务器接受以字节为单位的部分内容请求.

如果你在Fiddler中看到了一个HTTP/206响应,但你需要的是一个完整的文件(比如你想保存一个完整的视屏文件),你可以选中该会话按下U键,或者按住Ctrl键点击工具栏中的Replay按钮,执行无条件请求。

    今日读书，无法理解HTTP302、303、307状态码的来龙去脉，决定对其做深究并总结于本文。     《HTTP权威指南》第3章在讲解30X状态码时，完全没有讲清楚为什么要有302、303、307，以及他们的关系，一句“问题出在HTTP/1/1”让我一头雾水，莫名其妙；而第五章在讲重定向响应时，没有说到现在很常见的302，反而是说我从没遇到过的303和307。很是迷惑，对于这3个状态码，WiKi和RFC文档都有详解，下面我以我的思维添油加醋的描述一遍。

一、状态码——302

    RFC1945(http://tools.ietf.org/html/rfc1945#page-34)，也就是HTTP1.0在介绍302时说，如果客户端发出POST请求后，收到服务端的302状态码，那么不能自动的向新的URI发送重复请求，必须跟用户确认是否该重发，因为第二次POST时，环境可能已经发生变化（嗯，POST方法不是幂等的），POST操作会不符合用户预期。但是，很多浏览器（user agent我描述为浏览器以方便介绍）在这种情况下都会把POST请求变为GET请求。    RFC2616(http://tools.ietf.org/html/rfc2616#section-10.3.3)，也就是HTTP1.1在介绍302时说，如果客户端发出非GET、HEAD请求后，收到服务端的302状态码，那么就不能自动的向新URI发送重复请求，除非得到用户的确认。（又是-,-）但是，很多浏览器都把302当作303处理了（注意，303是HTTP1.1才加进来的，其实从HTTP1.0进化到HTTP1.1，浏览器什么都没动），它们获取到HTTP响应报文头部的Location字段信息，并发起一个GET请求。

二、状态码——303和307

    从上面的介绍可以知道，HTTP1.1和HTTP1.0的302状态码意义是一样的，浏览器对它的处理也是一样的。POST方法的重定向在未询问用户的情况下就变成GET，这种不符合文档规范的问题依然存在。实践在前而文档在后，HTTP1.1把这种POST变GET的行为纳入了RFC文档：HTTP1.1新加入303和307状态码。    文档中规定303状态码的响应，也就是上边提到的现在浏览器对302状态码的处理：POST重定向为GET。    HTTP1.1文档中307状态码则相当于HTTP1.0文档中的302状态码，当客户端的POST请求收到服务端307状态码响应时，需要跟用户询问是否应该在新URI上发起POST方法，也就是说，307是不会把POST转为GET的。    从网络上搜索到这个说法“303：对于POST请求，它表示请求已经被处理，客户端可以接着使用GET方法去请求Location里的URI。 307：对于POST请求，表示请求还没有被处理，客户端应该向Location里的URI重新发起POST请求。”，从上面的介绍可以明白，这个说法是臆想而已，文档并没有这么说，而业界是否统一如此处理，还不好说，我没有抓到过307和303的包。    文档也说到，为兼容很多HTTP1.1之前的浏览器，服务端在需要发出303状态码时，会选择用302状态码替代；而对于307的处理，则需要在响应实体中包含信息，以便不能处理307状态码的用户有能力在新URI中发起重复请求，也就是说，把重定向的页面展示给用户，让用户去点重定向URI链接（URI现在基本就是URL）。

三、总结

    303和307是HTTP1.1新加的服务器响应文档的状态码，它们是对HTTP1.0中的302状态码的细化，主要用在对非GET、HEAD方法的响应上。文档规定：浏览器对303状态码的处理跟原来浏览器对HTTP1.0的302状态码的处理方法一样；浏览器对307状态码处理则跟原来HTTP1.0文档里对302的描述一样。     303和307的存在，归根结底是由于POST方法的非幂等属性引起的。    在HTTP1.1中，302理论上是要被放弃掉的，它被细化为303和307，但为了兼容，它目前还在业界中大量使用，而303和307状态码我还没遇到过（没有使用场景，也没抓到过这样的响应报文）。为什么业界少使用303和307呢？对于GET和HEAD方法来说，307是没必要存在的，用302或者303就可以满足需求了，307仅在POST方法的重定向上有用处。所以我猜测它们少见的原因有两方面：1、POST方法重定向的使用场景太少，使得307状态码没有用武之地；2、GET方法虽然常需要使用的重定向，但使用302状态码也能正确运转，再考虑到微乎其微的兼容问题（现在的浏览器怎么可能不支持HTTP1.1呢！），也就没有使用303的必要了。 参考资料：1、HTTP 302 wiki http://en.wikipedia.org/wiki/HTTP_3022、RFC1945 http://tools.ietf.org/html/rfc1945#page-343、RFC2616 http://tools.ietf.org/html/rfc2616#section-10.3.3

在HTTP1.1协议下，HTTP状态码总共可分为5大类