http請求 HTTP/204和HTTP/206響應

上次我們講了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按鈕,執行無條件請求.

文章來源：http://www.cnblogs.com/ziyunfei/archive/2012/11/17/2775421.html