第二章 HTTP報文

如果說HTTP是因特網的信使，那麼HTTP報文就是它用來搬東西的包裹了。

---

報文流

HTTP報文是在HTTP應用程序之間發送的數據塊。這些數據塊以一些文本信息的元信息（meta-information）開頭，這些信息描述了報文的內容及含義後面跟着可選的數據部分。這些報文在客戶端、服務器和代理之間流動。術語”流入”、”流出”、”上游”、”下游”都是用來描述報文方向的。

• 報文流入源端服務器
  HTTP使用術語流入和流出來描述事務處理(transaction)的方向。報文流入源端服務器，工作完成之後，會流回用戶的Agent代理中。
  圖 報文流入源端服務器並流回到客戶端
  

• 報文向下遊流動
  HTTP報文會像河水一樣流動。不管是請求報文還是響應報文，所有報文都會向下游流動。所有報文的發送者都在接收者的上游。
  

---

報文的組成結構

HTTP報文是簡單的格式化數據塊。每條報文都包含一條來自客戶端的請求，或者一條來自服務器的響應。它們由三個部分組成：對報文進行描述的起始行，包含屬性的首部塊，以及可選的，包含數據的主體部分。

需要說明的是，儘管HTTP規範中說明應該用CRLF來表示行終止，但是穩健的應用程序也應該接受單個換行符作爲行的終止。有些老的，或者是不完成的HTTP應用程序並不總是既發送回車符又發送換行符

實體的主體或報文的主體（或者稱爲主體）是一個可選的數據塊。與起始行和首部不同的是，主體中可以包含文本或者二進制數據，也可以爲空。

---

報文的語法

所有的HTTP報文都可以分爲兩類：請求報文（request message）和響應報文（response message）。
請求報文會向Web服務器請求一個動作。響應報文會將請求的結果返回給客戶端。
請求報文和響應報文的基本報文結構相同。

請求報文的格式：

<method><request-URL><version>
<headers>

<entity-body>

響應報文的格式：

<version><status><reason-phrase>
<headers>

<entity-body>

對各部分的簡要描述

• 方法（method）：
  客戶端希望服務器對資源執行的動作。是一個單獨的詞，比如GET、HEAD或POST。
• 請求URL（request-URL）：
  命名了所請求資源，或者URL路徑組件完整URL。如果直接與服務器進行對話，只要URL的路徑組件是就資源的絕對路徑，通常就不會有什麼問題——服務器可以假定自己是URL的主機/端口。
• 版本（version）：
  報文所使用的HTTP版本，其格式看起來是這樣
  HTTP/<major>.<minor>
  其中主要版本號（major）和次要版本號都是整數。
• 狀態碼：
  這三位數字描述了請求過程中所發生的情況。每個狀態碼的第一位數字都用於描述狀態的一般類別（“成功”，“出錯”等）。
• 原因短語：
  數字狀態碼的可讀版本，包含行終止序列之前的所有文本。原因短語只對人類有意義。
• 首部（header）
  可以有零個或者多個首部，每個首部都包含一個名字，後面跟着一個冒號（：），然後是一個可選的空格，接着是一個值，最後是一個CRLF。首部是由一個空行（CRLF）結束的，表示了首部列表的結束和實體主體部分的開始。有些HTTP版本，比如HTTP/1.1，要求有效的請求或者響應報文中必須包含特定的首部。
• 實體的主體部分：
  實體的主體部分包含一個由任意數據組成的數據塊。並不是所有的報文都包含實體的主體部分，有時，報文只是以一個CRLF結束。

假想的請求和響應報文

請求報文：
GET /test/hi-there.txt HTTP/1.1             
Accept: text/*                              
Host:www.joes-hardware.com

響應報文：
HTTP/1.0 200 OK

Content-type:text/plain
Content-length: 19

Hi!I'm a message!

注意，一組HTTP首部總是應該以一個空行（單個CRLF）結束，甚至即使沒有首部和實體部分也應如此。但是由於歷史原因，很多客戶端和服務器都在沒有實體的主體部分時，（錯誤地）省略了最後的CRLF。爲了與這些流行但不符合規則的實現進行互通，客戶端和服務器都應該接受那些沒有最後那個CRLF的報文。

1.起始行

所有的HTTP報文都是以一個起始行作爲開始。請求報文的起始行說明了要做些什麼。響應報文的起始行說明發生了什麼。

• 請求行：請求報文請求服務器對資源進行一些操作。
  請求報文的起始行，或稱爲請求行，包含一個方法和一個請求URL，這個方法描述了服務器應該執行的操作，請求URL描述了要對哪個資源執行這個方法。請求行中還包含HTTP版本，用來告知服務器，客戶端使用的是哪種HTTP。所有這些字段都由空格符分隔。

• 響應行：響應報文承載了狀態信息和操作產生的所有結果數據，將其返回給客戶端。
  響應報文的起始行，或稱爲響應行，包含了響應報文使用的HTTP版本、數字狀態碼，以及描述操作狀態的文本形式的原因短語。所有這些字段都由空格符進行分隔。

• 方法：請求的起始行以方法作爲開始，方法用來告知服務器要做些什麼。
  HTTP規範中定義了一組常用的請求方法。

表 常用的HTTP方法

方法	描述	時候包含主體
GER	從服務器獲取一份文檔	否
HEAD	只從服務器獲取文檔的首部	否
POST	向服務器發送需要處理的數據	是
PUT	將請求的主體部分存儲在服務器上	是
TRACE	對可能經過代理服務器傳送到服務器上的報文進行追蹤	否
OPTIONS	決定可以在服務器上執行那些方法	否
DELETE	從服務器上刪除一份文檔	否

並不是所有的服務器都實現了上表中的列出的所有7中方法。而且由於HTTP設計得易於擴展，所以除了這些方法之外，其他服務器可能還會實現一些自己的請求方法。這些附加的方法是對HTTP規範的擴展，因此被稱爲擴展方法。

• 狀態碼：方法是用來告訴服務器做什麼事情的，狀態碼則是用來告訴客戶端發生了什麼事情。
  狀態碼位於響應的起始行中。比如，在行HTTP/1.0 200 OK中，狀態碼就是200.
  狀態碼實在每條響應報文的起始行中返回的。會返回一個數字狀態和一個可讀的狀態。數字碼便於程序進行差錯處理，而原因短語則更便於人們的理解。

表 狀態碼分類

整體範圍	已定義範圍	分類
100~199	100~101	信息提示
200~299	200~206	成功
300~399	300~305	重定向
400~499	400~415	客戶端錯誤
500~599	500~505	服務器錯誤

當前的HTTP版本只爲沒類狀態定義了幾個代碼。隨着協議的發展，HTTP規範中會正式地定義更多的狀態碼。如果收到不認識的狀態碼，可能是有人將其作爲當前協議的擴展定義的。可以根據其所處的範圍，將它作爲那個類別中一個普通的成員來處理。

比如，如果收到了狀態碼515（在狀態碼分類中所列5XX代碼的已定義範圍之外），就應該認爲這條響應指出了服務器的錯誤，這是5XX報文的通用類別。

• 原因短語：
  原因短語是響應起始行中的最後一個組件。它爲狀態碼提供了文本形式的解釋。比如，在行HTTP/1.0 200 OK中，OK就是原因短語。
• 版本號：
  版本號會以HTTP/x.y的形式出現在請求和響應報文的起始行中。使用 版本號的目的是爲使用HTTP的應用程序提供的一種線索，以便互相瞭解對方的能力和報文格式。
  

  注意：版本號不會被當做分數來處理。版本中的每個數字都會被當做一個單獨的數字來處理。因此，在比較HTTP版本時，每個數字都必須單獨進行比較，以便確定哪個版本更高。比如，HTTP/2.22就比HTTP/2.3版本要高，因爲22比3大。

2.首部

HTTP首部字段向請求和響應報文中添加一些附加信息。本質上來說，它們只是一些名/值對的列表。

• 首部分類

首部類別	功能
通用首部	既可以出現在請求報文中，也可以出現在響應報文中
請求首部	提供更多的有關請求的信息
響應首部	提供更多的有關響應的信息
實體首部	描述主體的長度和內容，或者資源自身
擴展首部	規範中沒有定義的新首部

每個HTTP首部都由一種簡單的語法：名字後邊跟着冒號（：），然後跟上可選的空格，再跟上字段值，最後一個是CRLF。

表 常見首部實例

首部實例	描述
Date:Tue,30ct 1997 02:16:03 GMT	服務器產生響應的日期
Content-length:15040	實體的主體部分包含了15040個字節的數據
Content-type:image/gif	實體的主體部分是一個GIF圖片
Accept: image/gif, image/jpeg, text/html	客戶端可以接收GIF圖片和JPEG圖片以及HTML

---

• 首部延續行
  將長的首部行分爲多行可以提高可讀性，多出來的每行前面至少要有一個空格或者製表符（tab）。
  例如：

HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Sercer: Test Server
    Version 1.0

在這個例子中，響應報文中包含了一個Server首部，其值被劃分成了多個延續行。

3.實體的主體部分

HTTP報文的第三部分時可選的實體主體部分。實體的主體是HTTP報文的負荷。就是HTTP要傳輸的內容。HTTP報文可以承載很多類型的數字數據：圖片、視頻、HTML文檔、軟件應用程序、信用卡事務、電子郵件等。

方法

注意：並不是每個服務器都實現了所有的方法，即使是服務器實現了所有的這些方法，這些方法的使用很可能也是受限制的。例如支持DELETE方法和PUT方法的服務器可能並不希望任何人都能刪除或者是存儲資源。這些限制通常都是在服務器的配置中進行設置的，因此會隨着站點和服務器的不同而有所不同。

1.安全的方法

HTTP定義了一組被稱爲安全方法的方法。GET方法和HEAD方法都被認爲是安全的，這就意味着使用GET和HEAD方法的HTTP請求都不會產生什麼動作。

不產生動作，在這裏意味着HTTP請求不會在服務器上產生什麼結果。例如，你在一家商店購物時，點擊了“提交購買”按鈕。點擊按鈕時會提交一個帶有信用卡信息的POST請求，那麼在服務器上，就會爲你執行一個動作。在這種情況下，爲購買行爲支付信用卡就是所執行的動作。

安全方法並不一定是什麼動作都不執行的（實際上這是由Web開發者決定的）。使用安全方法的目的就是允許HTTP應用程序開發者通知用戶，什麼時候會使用某個可能引發某些動作的不安全方法。在商店的例子中，你的Web瀏覽器可能會彈出一條警告消息，說明你正在用不安全的方法發起請求，這樣可能會在服務器上引發一些事件。

2.GET

GET是最常用的方法，通常用於請求服務器發送某個資源。

3.HEAD

HEAD方法與GET方法的行爲很類似，但是服務器在響應中只返回首部。不會反悔實體的主體部分。這就允許客戶端在未獲取實際資源的情況下，對資源的首部進行檢查。使用HEAD，可以：

1.在不獲取資源的情況下了解資源的情況（比如判斷其類型）。
2.通過查看響應中的狀態碼看看某個對象是否存在。
3.通過查看首部，測試資源是否被修改了。

服務器開發者必須確保返回的首部與GET請求所返回的首部完全相同。

4.PUT

與GET從服務器讀取文檔相反，PUT方法會向服務器寫入文檔。有些發佈系統允許用戶創建Web頁面，並用PUT直接將其安裝到Web服務器上。
PUT方法的語義就是讓服務器用請求的主體部分來創建一個由所請求的URL命名的新文檔，或者，如果那個URL已經存在的話，就用這個主體來替代它。
因爲PUT允許用戶對內容進行修改，所以很多Web服務器都要求在執行PUT之前，用密碼登錄。

5.POST

POST方法起初是用來向服務器輸出數據的。實際上，通常會用它來支持HTML的表單。表單中填好的數據通常會被送給服務器，然後由服務器將其發送到它要去的地方（比如，送到一個服務器網關程序中，然後由這個程序對其進行處理）。

6.TRACE

客戶端發起一個請求時，這個請求可能要穿過防火牆、代理、網關或其他一些應用程序。每個中間節點都可能會修改原始的HTTP請求。TRACE方法允許客戶端在最終將請求發送給服務器時，看看它變成了什麼樣子。

TRACE請求會在目的服務器端發起一個“環回”診斷。行程最後一站的服務器會彈回一條TRACE響應，並在響應主體中攜帶它收到的原始請求報文。這樣客戶端就可以查看在所有中間HTTP應用程序組成的請求/響應鏈上，原始報文是否，以及如何被毀壞或修改過。

TRACE方法只要用於診斷，也就是說，用於驗證請求是否如願穿過了請求/響應鏈。它也是一種很好的工具，可以用來查看代理和其他應用程序對用戶請求所產生的效果。

TRACE請求中不能帶有實體的主體部分。TRACE響應的實體主體部分包含了響應服務器收到的請求的精確副本。

7.OPTIONS

OPTIONS方法請求WEB服務器告知其支持的各種功能。可以詢問服務器通常支持哪些方法，或者對某些特殊資源支持哪些方法。
這爲客戶端應用程序提供了一種手段，使其不用實際訪問哪些資源就能判定訪問各種資源的最優方式。

8.DELETE

顧名思義，DELETE方法所做的事情就是請求服務器刪除請求URL中所指定的資源。但是，客戶端應用程序無法保證刪除操作一定會被執行。因爲HTTP規範允許服務器在不通知客戶端的情況下撤銷請求。

9.擴展方法

HTTP被設計成字段可擴展的，這樣新的特性不會使老的軟件失效了。擴展方法指的是沒有在HTTP/1.1規範中定義的方法。服務器會爲它所管理的資源實現一些HTTP服務，這些方法爲開發者提供了一種擴展這些HTTP服務能力的手段。

表 Web發佈擴展方法示例

方法	描述
LOCK	允許用戶“鎖定”資源——比如，可以在編輯某個資源的時候將其鎖定，以防別人同時對其進行修改
MKCOL	允許用戶創建資源
COPY	便於在服務器上覆制資源
MOVE	在服務器上移動資源

並不是所有的擴展方法都是在正式規範中定義的，認識到這一點很重要。如果你定義了一個擴展方法，很可能大部分HTTP應用程序都無法理解。同樣你的HTTP應用程序也可能會遇到一些其他應用程序在用的，而它並不理解的擴展方法。

在這些情況下，最好對擴展方法寬容一些。如果能夠在不破壞端到端行爲的情況下將帶有未知方法的報文傳遞給下游服務器的話，代理會嘗試着傳遞這些報文的。否則，它們會以501 Not Imple（無法實現）狀態碼進行響應。最好按照慣例“對所發送的內容要求嚴一點，對所接受的內容寬容一些”來處理擴展方法（以及一般的HTTP擴展）。

狀態碼

狀態碼爲客戶端提供了一種理解事務處理結果的便捷方式。

• 100~199——信息性狀態碼
  HTTP/1.1向協議中引入了信息性狀態碼。這些狀態碼相對較新，由於對其複雜性和感知價值存在一些爭論而受到限制。

表 信息性狀態碼及短語

狀態碼	原因短語	含義
100	Continue	說明收到了請求的初始部分，請客戶端繼續。發送了這個狀態碼之後，服務器在收到請求之後必須進行響應。
101	Switching Protocols	說明服務器正在根據客戶端的指定，將協議切換成Update首部所列的協議

100 Continue狀態碼尤其使人糊塗。它的目的是對這樣的情況進行優化：HTTP客戶端應用程序有一個實體的主體部分要發送給服務器，但是希望在發送之前查看一下服務器是否會接受這個實體。這可能會給HTTP程序員帶來一些困擾，因此在這裏進行了比較詳細的討論。（它如何與客戶端、服務器和代理進行通信）

• 200~299——成功狀態碼
  客戶端發起請求時，這些請求通常都是成功的。服務器有一組用來表示成功的狀態碼，分別對應不同類型的請求。

表 已定義的成功狀態碼

狀態碼	原因短語	含義
200	OK	請求成功，實體的主體部分包含了所請求的資源
201	Create	用於創建服務器對象的請求（比如PUT）。響應的實體部分中應該包含各種引用了已創建的資源的URL，Location首部包含的則是最具體的引用。服務器必須在發送這個狀態碼之前創建好對象。
202	Accepted	請求已被接受，但服務器還未對其執行任何動作。不能保證服務器會完成這個請求；這只是意味着接受請求時，它看起來是有效的。服務器應該在實體的主體部分包含對請求狀態的描述，或許還應該有對請求完成時間的估計（或者包含一個指針，指向可以獲取此信息的位置）
203	Non-Authoritative Information	實體首部包含的信息不是來自於源端服務器，而是來自於資源的一份副本。如果中間節點上有一份資源副本，但是無法或者沒有對它所發送的與資源有關的元信息（首部）進行驗證，就會出現這種情況。這種相應碼並不是非用不可的，如果實體首部來自源端服務器，響應爲200狀態的應用程序就可以將其作爲一種可選項使用。
204	No Content	響應報文中包含若干首部和一個狀態行，但是沒有實體的主體部分，主要用於在瀏覽器不轉爲顯示新文檔的前提下，對其進行更新（比如刷新一個表單頁面）
205	Reset Content	另一個主要用於瀏覽器的代碼。負責告知瀏覽器清除當前頁面中所有HTML表單元素
206	Partial Content	成功執行了一個部分或Range（範圍）請求。客戶端可以通過一些特殊的首部來獲取部分或某個範圍內的文檔——這個狀態碼就說明範圍請求成功了。206響應中必須包含Content——Range、Data以及ETag或Content——Location首部。

• 300~399
  

  重定向狀態碼要麼告知客戶端使用替代位置來訪問他們所感興趣的資源，要麼就提供一個替代的響應而不是資源內容。如果資源已經被移動，可發送一個重定向狀態碼和一個可選的Location首部來告知客戶端資源已經被移動走了以及現在可以在哪裏可以找到它。這樣瀏覽器就可以在不打擾使用者的情況下，透明的轉入新的位置。

表 重定向狀態碼與原因短語

狀態碼	原因短語	含義
300	Multiple Choices	客戶端請求一個實際指向多個資源的URL時會返回這個狀態碼，比如服務器上有個HTML文檔的英語和法語版本。返回這個代碼時會帶有一個選項列表；這樣的用戶就可以選擇他希望使用的那一項了，
301	Moved Permanently	在請求的URL已被移除時使用。響應的Location首部中應該包含資源現在所處的URL
302	Found	與301狀態碼類似；但是，客戶端應該使用Location首部給出的URL來臨時定位資源。將來的請求仍應使用老的URL
303	See Other	告知客戶端應該用另一個URL來獲取資源。新的URL位於響應報文的Location首部。其主要的目標是允許POST請求的響應將客戶端定向到某個資源上去。
304	Not Modified	客戶端可以通過所包含的請求首部，使其請求變成有條件的。如果客戶端發起了一個條件GET請求，而最近資源沒有被修改的話，就可以用這個狀態碼來說明資源未被修改。帶有這個狀態碼的響應不應該包含實體的主體部分。
305	Use Proxy	用來說明必須通過一個代理來訪問資源；代理的位置由Location首部給出。很重要的一點是，客戶端是相對某個特殊資源來解析這條響應的，不能假定所有請求，甚至所有對持有所請求資源的服務器的請求都通過這個代理進行。如果客戶端錯誤地讓代理介入了某條請求，可能會引發破壞行爲，而且會造成安全漏洞。
306	（未使用）	當前未使用
307	Temporary Redirect	與301狀態碼類似；但客戶端應該使用Location首部給出的URL來臨時定位資源。將來的請求應該使用老的URL。

狀態碼302、303和307狀態碼之間存在一些交叉。這些狀態碼的用法有着細微額差別，大部分差別都源於HTTP/1.0和HTTP/1.1應用程序對這些狀態碼處理方式不同。

當HTTP/1.0客戶端發起一個POST請求，並在響應中收到302重定向狀態碼時，它會接受Location首部的重定向URL，並向那個URL發起一個GET請求（而不會像原始請求中那樣發起POST請求）。

HTTP/1.0服務器希望HTTP/1.0客戶端這麼做——如果HTTP/1.0服務器收到來自HTTP/1.0客戶端的POST請求之後發送了302狀態碼，服務器就期望客戶端能夠接受重定向URL，並向重定向的URL發送一個GET請求。

問題出在HTTP/1.1。HTTP/1.1規範使用303狀態碼來實現同樣的行爲（服務器發送303狀態碼來重定向客戶端的POST請求，在它後面跟上一個GET請求）。

爲了避開這個問題，HTTP/1.1規範指出，對於HTTP/1.1客戶端，用307狀態碼取代302狀態碼來進行臨時重定向。這樣服務器就可以302狀態碼保留起來，爲HTTP/1.0客戶端使用了。

這樣一來，服務器要選擇適當的重定向狀態碼放入重定向響應中發送，就需要查看客戶端的HTTP版本了。

• 400~499——客戶端錯誤狀態碼
  表 客戶端錯誤狀態碼及原因短語

狀態碼	原因短語	含義
400	Bad Request	用於告知客戶端它發送一個錯誤地請求
401	Unauthorized	與適當的首部一同返回，在這些首部中請求客戶端在獲取對資源的訪問權之前，對自己進行認證。
402	Payment Required	現在這個狀態碼還未使用，但是已經被保留，以作未來只用
403	Forbidden	用於說明請求被服務器拒絕了。如果服務器想說明爲什麼拒絕請求，可以包含實體的主體部分來對原因進行描述。但是這個狀態碼通常是在服務器不想說明拒絕原因是的時候使用的
404	Not Found	用於說明服務器無法找到所請求的URL。通常會包含一個實體，以便客戶端應用程序顯示給用戶看
405	Method Not Allowed	發起的請求中帶有所請求的URL不支持的方法時，使用此狀態碼。應該在響應中包含Allow首部，以告知客戶端對所請求的資源可以使用哪些方法。
406	Not Acceptable	客戶端可以指定參數來說明他們願意接受什麼類型的實體。服務器沒有與客戶端可接受的URL相匹配的資源時，使用此代碼。通常，服務器會包含一些首部，以便客戶端弄清楚爲什麼請求無法滿足。
407	Proxy Authentication Requireed	與401狀態碼類似，但是用於要求對資源進行認證的代理服務器。
408	Request Timeout	如果客戶端完成請求花費的時間太長，服務器可以會送此狀態碼，並且關閉連接。超時時長隨服務器的不同有所不同，但是通常對所有的合法請求來說，都是夠長的。
409	Conflic	用於說明請求可能在資源上引發的一些衝突。服務器擔心請求會引發衝突時，可以發送此狀態碼。響應中應該包含描述衝突的主體。
410	Gone	與404類似，只是服務器曾經擁有過此資源。主要用於Web站點的維護，這樣服務器的管理者就可以在資源被移除的情況下通知客戶端了
411	Length Required	服務器要求在請求報文中包含Content-Length首部時使用。
412	Precondition Failed	客戶端發起了條件請求，且其中一個條件失敗了的時候使用，客戶端包含了Except首部時發起的就是條件請求。
413	Request Entity Too large	客戶端發送的實體主體部分比服務器能夠或者希望處理的要大時，使用此狀態碼。
414	Request URL Too Long	客戶端發送請求中的請求URL比服務器能夠或者希望處理的要長時，使用此狀碼
416	Requested Range Not Satisfiable	請求報文所請求的是指定資源的某個範圍，而此範圍無效或無法滿足時，使用此狀態碼。
417	Expectation Failed	請求的Expect請求首部包含了一個期望，但服務器無法滿足此期望時，使用此狀態碼。如果有代理或其他中間應用程序有確切證據說明源端服務器會爲某請求產生一個失敗的期望，就可以發送這個響應狀態碼。

---

• 500~599——服務器錯誤狀態碼
  

有時客戶端發送了一條有效請求，但是服務器自身卻出錯了。這可能是客戶端碰上了服務器的缺陷，或者服務器上的子元素，比如某個網關資源出了錯。

代理嘗試着代表客戶端與服務器進行交流時，經常會出現問題。代理服務器會發布5XX服務器錯誤狀態碼來描述所遇到的問題。

---

表 服務器錯誤狀態碼及原因短語

狀態碼	原因短語	含義
500	Internal Server Error	服務器遇到一個妨礙它爲請求提供服務的錯誤時，使用此狀態碼
501	Not Implemented	客戶端發起的請求超出服務器的能力範圍（比如，使用了服務器不支持的請求方法）時，使用此狀態碼。
502	Bad Gateway	作爲代理或網關使用的服務器從請求響應鏈的下一條鏈路上收到了一條僞響應（比如，它無法連接到其父網關）時，使用此狀態碼。
503	Service Unavailable	用來說明服務器現在無法爲請求提供服務，但是將來可以。如果服務器知道什麼時候資源會變爲可用的，可以在響應中包含一個RetryAfter首部。
504	Gateway TimeOut	與狀態碼408類似，只是這裏的響應來自一個網關或代理，它們在等待另一臺服務器對其請求進行響應超時了。
505	HTTP Version Not Supported	服務器收到的請求使用了它無法或不願意支持的協議版本時，使用此狀態碼。有些服務器應用程序會選擇不支持協議的早期版本。

首部

首部和方法配合工作，共同決定了客戶端和服務器能做什麼事情。在請求和響應報文中都可以用首部來提供信息，有些首部是某種報文專用的，有些是更爲通用的。

首部可以分爲5個主要的類型

• 通用首部
  這些是客戶端和服務器都可以使用的通用首部。可以在客戶端、服務器和其他應用程序之間提供一些非常有用的通用功能。比如Date首部就是一個通用首部，每一端都可以用它來說明構建報文的時間和日期：
  Date: Tue, 3 Oct 1974 02:16:00 GMT
• 請求首部
  從名字就可以看出來，請求首部就是請求報文特有的。它們爲服務器提供了一些額外的信息，比如客戶端希望接收什麼類型的數據。例如，下例中的Accept首部就用來告知服務器客戶端會接受與其請求相符的任意媒體類型：
  Accept： */*
• 響應首部
  響應報文有自己的首部集，以便爲客戶端提供信息（比如，客戶端在與哪種類型的服務器進行交互）。例如，下例Server首部就用來告知客戶端它在與一個版本1.0的Tiki-Hui服務器進行交互：
  Server： Tiki-Hut/1.0
• 實體首部
  實體首部指的是用於應對實體主體部分的首部。比如，可以用實體首部來說明實體主體部分的數據類型。
• 擴展首部
  擴展首部是非標準的首部，由應用程序開發者創建，但還未添到已批准的HTTP規範中去。即使不知道這些擴展首部的含義，HTTP程序也要接受它們並對其進行轉發。