## 簡介 目前為止我們已經發起了各種各樣的請求，也看到了服務器發回的原始 HTTP 數據。服務器返回的原始數據就是所謂的**響應**。本章我們會分析 HTTP 響應里的各種組成部分。 ## 狀態碼 我們要看的第一個組成部分是 HTTP 狀態碼.`狀態碼`是服務器接收到請求后返回的標識請求狀態的三位數.在`狀態碼`的旁邊，就是描述這個狀態碼的`狀態文本`.一般這些出現在審查器的`Status`這列:  你遇到的最常見的響應狀態碼應該是 200，意思是請求被正確處理.讓我們來看看其他有用的狀態碼: | 狀態碼 | 狀態文本 | 含義 | | --- | --- | --- | | 200 | OK | 請求被正確處理 | | 302 | Found | 所請求的資源已暫時更改.通常會重定向到另一個 URL | | 404 | Not Found | 所請求的資源無法找到 | | 500 | Internal Server Error | 服務器出現一般性錯誤 | 作為一個 web 開發者，你應該熟知上面的響應狀態碼和其代表的含義。 讓我們來挨個舉例看看: ## 302 Redirect（重定向） 當一個資源的位置移動了會發生什么呢？ 最通用的解決方案是把對舊 URL 的請求重新引導到新 URL 上.這種重新引導請求的行為有一個術語叫`重定向`（ redirect ）。當你的瀏覽器看到一個 302 響應狀態碼的時候，他就知道這個資源已經移動到別處了，然后就會自動跳轉到?`Location`?響應頭部里指定的 URL 。在本節中，我們會用瀏覽器和 HTTP 工具來演示重定向。 比如說你想要看?[GitHub](http://www.github.com/)?上的賬戶配置，你就要訪問這個鏈接?`https://github.com/settings/profile`?。但是，要有訪問賬戶配置頁面的權限，你必須先登錄。如果你沒有登錄就訪問這個鏈接，瀏覽器會把你送到登錄頁面去。當你填寫正確的登錄信息后，你就會被重定向到你最早想訪問的頁面。這個是大多數 web 應用的通用工作流程。讓我們看看瀏覽器和 HTTP 工具是怎么處理這個流程的。 首先你在瀏覽器里輸入?`https://github.com/settings/profile`?。 因為瀏覽器很聰明，它會直接按照重定向的指示給你展示出 GitHub 的登錄頁面:  相比之下我們來看看 HTTP 工具 （注意狀態碼），它并沒有自動跟進重定向:  注意這個?`Location`?響應頭部（有點難找到，在第 12 行）。你應該能看到 ~~~ Location: https://github.com/login?return_to=https%3A%2F%2Fgithub.com%2Fsettings%2Fprofile ~~~ 這個 URL 里有一個?_return_to_?參數，它的值就是在登錄之后客戶端要重定向到的 URL。對比一下瀏覽器里那張圖，你應該能發現，這個 URL 和瀏覽器地址欄里的 URL 是一樣的。 ## 404 Not Found（未找到） 接下來，我們看看瀏覽器里的 404 響應狀態碼是什么樣。當所請求的資源沒有找到的時候，服務器會返回這個狀態碼。要記得，資源可以是任何東西，包括音頻文件，CSS 文件，javascript 文件，圖片等等。讓我們給`http://www.dropbox.com`?發一個?`GET`?請求索要一張圖片，`https://www.dropbox.com/awesome_file.jpg`:  我們看到了 Dropbox 那漂亮的 404 頁面。現在讓我們在 HTTP 工具里看看同樣的請求的響應:  因為我們索要的資源并不存在，瀏覽器給我們展示了一個格式友好的文字提示，但 HTTP 工具會給我們展示響應狀態碼和原始響應數據。 ## 500 Internal Server Error（內部服務器錯誤） 一個 500 狀態碼意思就是'服務器那兒好像出了點兒問題'。 這只是一個一般性的錯誤狀態碼，造成這個錯誤的原因可能是服務器配置，也可能是跑在服務器上的應用里的代碼少寫個逗號。但是不管是什么問題，總之是服務器端有問題。有服務器訪問權限的人必須去調試和解決這個問題，這就是為什么很多含糊的報錯信息都會提醒你去聯系你的系統管理員。在實際應用上，500 錯誤也可以像 404 那樣以多種多樣的形式顯示出來。下面就是 rails 應用默認的 500 頁面：  使用 HTTP 工具，我們能看到狀態碼和原始數據：  ## 響應頭部 跟請求頭部一樣，我們也可以用審查器去看響應頭部：  響應頭部提供了更多關于服務器返回的資源的信息。讓我們來看看一些常見的響應頭部: | 頭部名稱 | 描述 | 舉例 | | --- | --- | --- | | Content-Encoding | 數據的編碼類型 | Content-Encoding: gzip | | Server | 服務器的名稱 | Server:thin 1.5.0 codename Knife | | Location | 通知客戶端新的資源位置 | Location:?[http://www.github.com/login](http://www.github.com/login) | | Content-Type | 響應數據的類型 | Content-Type:text/html; charset=UTF-8 | 還有很多響應頭部，但是跟請求頭部一樣，沒有必要去背下來。 響應頭部對返回的數據有著微妙的影響，有些情況下，它們巧妙的用于工作流程中（比如，你的瀏覽器自動跟進?`Location`?響應頭部指向的 URL ）。你需要理解的僅僅是，響應頭部包含了一些關于返回的響應數據的額外信息（譯注：描述數據的信息/數據，通常被稱為為元數據，meta-data or meta information ）。 ## 小結 在本章，我們討論了 HTTP 響應的組成部分。我們也了解了如何使用審查器去查看 HTTP 響應的頭部。盡管我們只是揭開了 HTTP 協議面紗的一角，我希望這些知識在你需要的時候能給你?[深入研究 HTTP](http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol)?的能力。 總之，我們已經看到，HTTP 只不過是一個協議，用于指示客戶端與服務器之間如何使用某種格式的文本進行通信。 HTTP 響應中最重要的部分如下: * 狀態碼 * 頭部 * 消息正文，里面有原始響應數據 試試看，在下面這個圖里你能不能找到上面那幾個部分都在哪兒: