當我們請求的物件在伺服器上並不存在時，就會給出這個返回**，這可能也是最常見的錯誤**了。iis給出的404訊息內容很長，除了訊息頭以外還有乙個完整的說明「為什麼會這樣」的網頁。apache伺服器的404訊息比較簡短，如下：
也許你會問，無論是404還是200，都會在訊息體內給出乙個說明網頁，那麼對於客戶端來說二者有什麼區別呢？乙個比較明顯的區別在於200是成功請求，瀏覽器會記錄下這個位址，以便下次再訪問時可以自動提示該位址，而404是失敗請求，瀏覽器只會顯示出返回的頁面內容，並不會記錄此位址，要再次訪問時還需要輸入完整的位址。
當web伺服器不允許匿名訪問，而我們又沒有提供正確的使用者名稱/密碼時，伺服器就會給出這個返回**。在iis中，設定iis的安全屬性為不允許匿名訪問（如下圖），此時直接訪問的話就會得到以下返回結果：
……此時瀏覽器上給出的提示如下圖，讓我們輸入使用者名稱和密碼：
因返回資訊中訊息體較長，只取前面兩行內容。注意，如果是用localhost來訪問本機的iis，因ie可以直接取得當前使用者的身份，它會和伺服器間直接進行協商，所以不會看到401提示。
當我們在輸入了使用者名稱和密碼以後，伺服器與客戶端會再進行兩次對話。首先客戶端向伺服器索取乙個公鑰，伺服器端會返回乙個公鑰，二者都用base64編碼，相應的訊息如下（編碼部分已經做了處理）：
……客戶端拿到公鑰之後使用公鑰對使用者名稱和密碼進行加密碼，然後把加密以後的結果重新發給伺服器：
這樣，如果驗證通過，伺服器端就會把請求的內容傳送過來了，也就是說禁止匿名訪問的**會經過三次請求才可以看到頁面。但因為客戶端瀏覽器已經快取了公鑰，用同乙個瀏覽器視窗再次請求這個**上的其它頁面時就可以直接傳送驗證資訊，從而一次互動就可以完成了。
用過asp的人都知道asp中頁面重定向至少有redirect和transfer兩種方法。二的區別在於redirect是客戶端重定向，而transfer是伺服器端重定向，那麼它們具體是如何通過http訊息頭實現的呢？
先來看一下transfer的例子：
例如asp檔案1.asp只有一行
<% server.transfer "1.htm" %>
html檔案1.htm也只有一行：
this is 1.htm
如果我們從瀏覽器裡請求1.asp，傳送的請求是：
注意請求的檔案確實是1.asp，而得到的回應則是：
不難看出，通過server.transfer語句伺服器端已經做了頁面重定向，而客戶端對此一無所知，表面上看上去得到的就是1.asp的結果。
如果把1.asp的內容改為：
<% response.redirect "1.htm" %>
再次請求1.asp，傳送的請求沒有變化，得到的回應卻變成了：
注意http的返回**由200變成了302，表示這是乙個重定向訊息，客戶端需要根據訊息頭中location欄位的值重新傳送請求，於是就有了下面一組對話：
很明顯，兩種重定向方式雖然看上去結果很像，但在實現原理上有很大的不同。
500號錯誤發生在伺服器程式有錯誤的時候，例如，asp程式為
<% if %>
顯然這個程式並不完整，於是得到的結果為：
伺服器傳送了500號錯誤，並且後面通過html的方式說明了錯誤的原因。
理解HTTP訊息頭 （四）
伺服器返回的http訊息也分為訊息頭和訊息體兩部分。前面 的第二篇裡已經介紹了返回訊息中常見返回 的含義。對於非正常的返回 的處理比較簡單，只要照著要求去做就好了，而對於正常的返回 200 其處理方式就多種多樣了。content type是返回訊息中非常重要的內容，它標識出這個返回內容的型別，其值為...
理解HTTP訊息頭 （四）
伺服器返回的http訊息也分為訊息頭和訊息體兩部分。前面 的第二篇裡已經介紹了返回訊息中常見返回 的含義。對於非正常的返回 的處理比較簡單，只要照著要求去做就好了，而對於正常的返回 200 其處理方式就多種多樣了。content type是返回訊息中非常重要的內容，它標識出這個返回內容的型別，其值為...
http請求訊息頭與響應訊息頭
請求頭 accept 客戶機通過這個頭，告訴伺服器，它支援哪些資料型別 accept charset 客戶機通過這個頭，告訴伺服器，它支援的編碼 accept encoding 客戶機通過這個頭，告訴伺服器，支援哪種資料壓縮格式 accept language 客戶機採用的是哪個語言 host 客戶...