本內容摘抄自《RESTful WebServices》 中文譯本附錄C '常見的HTTP報頭'。
原文作者：Leonard Ricbardson & Sam Ruby
翻譯：徐涵、李紅軍、胡偉
標准報頭
- Accept
類型：請求報頭。
重要程度：中等。
客戶端通過Accept報頭告訴服務器，它希望服務器采用什么表示格式返回，有的客戶端也許期望JSON，有的也許期望xml。
對於web瀏覽器而言，把這一信息放在HTTP報頭里是個不錯的主意，但是對於web服務客戶端而言，不應將此作為唯一的解決方案。
- Accept-Charset
類型：請求報頭。
重要程度：低。
客戶端通過該報頭告訴服務器，它希望服務器為表示采用什么字符集。例如有些期望UTF-8。
- Accept-Encoding
類型：請求報頭。
重要程度：中等到高。
客戶端通過該報頭告訴服務器，可以通過compress或gzip這些眾所周知的壓縮算法對響應體進行壓縮，從而節省寬帶。它和字符集編碼無關。
- Accept-Language
類型：請求報頭。
重要程度：低。
客戶端可以通過該報頭告訴服務器，它希望為表示采用哪種人類語言。
- Accept-Ranges
類型：響應報頭。
重要程度：低到中等。
服務器發送這個報頭，表明它支持部分HTTP GET（partial HTTP GET）。客戶端可以先發送一個HEAD請求，以便獲取服務器返回的Accept-Ranges報頭，然后再發送包含Range報頭的GET請求，以獲取資源的部分表示。
- Age
類型：響應報頭。
重要程度：低。
假如響應主體不是服務器剛剛生成的，那么可以通過該報頭表明它在服務器上存在多久了。這個報頭通常由HTTP緩存來設置，以便讓客戶端知道它得到的表示可能是一個舊的副本。
- Allow
類型：響應報頭。
重要程度：目前很低，可能會變高（2008年）
用於響應OPTIONS請求，以告訴客戶端一個特定資源支持哪些HTTP方法。
- Authorization
類型：請求報頭。
重要程度：非常高。
這個請求報頭包含認證證書，例如一個按特定認證方案進行編碼的用戶名和密碼。服務器收到包含Authorization報頭的請求后，將先解碼其中的證書，然后確定是否執行該請求。
理論上人們只需要Authorization這一個認證報頭就夠了（Proxy-Authorization是一個例外，因為它在一個不同的層次上工作），因為它是可擴展的。但是在實踐中，仍有自定義認證報頭的情況，比如說基於Authorization報頭的X-WSSE。HTTP基本認證和HTTP摘要認證是最常見的認證方案，不過只要客戶端和服務器雙方均能理解，采用任何方案都可以。
- Cache-Control
類型：請求/響應報頭。
重要程度：中等。
此報頭用於給客戶端和服務器之間的緩存（包括客戶端和服務器自身的緩存）下達指示。它明確指出緩存的規則，以及何時清除緩存。
例如：
Cache-Control：max-age=36000 緩存3600秒
Cache-Control：no-cache 禁用緩存
Cache-Control：private 只能被客戶單緩存不能被代理緩存
- Connection
類型：響應報頭。
重要程度：低。
大多數HTTP響應是從服務器到客戶端的通信。介於服務器與服務端之間的媒介（比如代理）能夠查看響應，但它不以此為主要目的。不過服務器可以額外附加一些面向代理的特殊報頭，而且一個代理可以附加一些面向下一個代理的特殊報頭。它們把這些特殊報頭的名稱寫在Connection報頭里。這些特殊報頭是針對兩個機器間的TCP連接的，而不是針對服務器與客戶端間的HTTP連接的，代理應該在把響應轉發出去之前，先把其中的特殊報頭以及Connection報頭本身去掉。當然，如果它需要，可以再附加一些新的特殊報頭和一個Connection報頭。如果你正在編寫客戶端，而且不准備使用代理，那么你可能遇到的唯一一個Connection報頭的值是“close”。它的意思是，服務器將在處理好本次請求之后，把TCP連接關閉。
- Content-Encoding
類型：響應報頭。
重要程度：中等到高。
該報頭與Accept-Encoding請求報頭相對。表示服務器實際采用的是什么壓縮算法。
- Content-Language
類型：響應報頭。
重要程度：中等。
該報頭與Accep-Language請求報頭相對。表示響應主體所采用的自然語言，它可能會列出多個語言。
- Content-Length
類型：響應報頭。
重要程度：高。
此響應報頭給出實體主體的大小（以字節為單位）。它有兩個重要用途：
1、客戶端可以讀取這個報頭，並為讀取主體實體做好准備。
2、客戶端可以通過做一次HEAD請求來獲知實體主體的大小，而不必真實的請求實體主體。
它可能回影響到客戶端作出“是獲取整個表示，還是部分表示，抑或不獲取表示”的決定。
- Content-Location
類型：響應報頭。
重要程度：低。
此響應報頭把所請求資源的規范URI告訴客戶端。跟Location報頭不同的，Content-Location報頭完全是信息性的，它並不要求客戶端使用新的URI。
當服務為同一個資源的不同表示分配了不同的URIs時，該報頭會比較有用。比如說，假如客戶端想得到一個資源的”與特定表示無關“的通用版本，那么服務器就可以把該通用版本的URI在Content-Location報頭中給出。所以，當你請求具有特定格式與語言的/releases/104.html.en時，服務器會在響應里把Content-Location報頭的值設為/releases/104。
- Content-MD5
類型：響應報頭。
重要程度：低到中等。
這是實體主體的加密校驗和。客戶端可以用它來檢查實體主體有沒有在傳送過程中被損壞。由於攻擊者可以同時篡改實體主體和Content-MD5報頭，所以這個報頭不是用於安全性目的，而只是用作錯誤檢測的。
- Content-Range
類型：響應報頭。
重要程度：低到中等。
當客戶端用Range請求報頭做部分GET請求時，服務器通過此響應報頭告訴客戶端它正在獲取哪部分表示。
- Content-Type
類型：響應報頭。
重要程度：非常高。
毫無疑問，這是最為著名的響應報頭。這個響應報頭告訴客戶端實體主體是什么媒體類型。
- Date
類型：請求/響應報頭。
重要程度：作為請求報頭高，作為響應報頭是必需的。
作為請求報頭，它表示客戶端發送請求的時間。作為響應報頭，它表示服務器完成請求的時間。作為響應報頭時，Date報頭被緩存所使用。
- ETag
類型：響應報頭。
重要程度：非常高。
ETag的值是一個不透明的字符串，它用於指示一個表示的特定版本。若表示發生改變，ETag也應隨之改變。應盡量為GET請求的響應提供此報頭。客戶端將來進行條件GET時，需要用到ETag報頭的值，客戶端在做條件GET請求時，把ETag報頭的值放在If-None-Match請求報頭里，服務器可以通過If-None-Match請求報頭的值判斷客戶端保存的表示是不是最新的，如果是最新的，服務器就不必重復發送表示，以節省時間和寬帶。
條件GET請求主要是靠Last-Modified響應報頭及與之相對的If-Modified-Since請求報頭實現的。ETag的主要目的是提供雙重保險。因為假如一個表示在一秒鍾內改變兩次的話，靠Last-Modified-Since是反映不出這個變化的，但ETag可以。
- Expect
類型：請求報頭。
重要程度：中等。
這個報頭用於LBYL請求。若服務器返回響應代碼100，那么客戶端可以繼續發送真正的請求。若服務器返回響應代碼417，那么客戶端應該放棄發送真正的請求。
- Expires
類型：響應報頭。
重要程度：中等。
這個報頭告訴客戶端（或介於服務器與客戶端之間的代理），可以在一段時間內對響應（整個響應，而不僅僅是實體主體）進行緩存。條件HTTP GET需要做一次HTTP連接，
並花費一定的時間與資源。而Expires使客戶端可以根本不用發送任何HTTP請求--至少在一段時間內。
- From
類型：請求報頭。
重要程度：非常低。
這個報頭跟電子郵件里的From字段的作用類似。它給出請求發送者的一個Email地址。由於隱私原因，這個報頭在human web上根本不被采用，而在“客戶端不在人類用戶直接控制下“的程序上就更不用說了。你也許可以將它作為User-Agent的一個擴展。
- Host
類型：請求報頭。
重要程度：必需的。
此報頭包含URI的域名部分。比如url為：http://www.example.com/page.html，則URI路徑是：/page.html, Host報頭的值是：“www.example.com“或者”www.example.com:80“。
從客戶端角度來看，可能無法理解為什么需要提供這樣一個報頭。由於HTTP 1.1服務器可以在一個IP地址上支持任意個域名，所以這個報頭是必需的。
這一特性叫做“基於域名的虛擬主機”，它使得擁有多個域名的人不必為每個域名單獨購買獨立的計算機與網卡。問題是，HTTP客戶端是向IP地址（而不是域名）發送請求的。所以如果沒有Host報頭，服務器就無法得知客戶端請求的目標是哪個虛擬主機。
- If-Match
類型：請求報頭。
重要程度：中等。
我們可以用其他報頭來間接描述這個報頭。它跟If-Unmodified-Since一樣，用於給除GET以外的HTTP動作設置條件。指示If-Unmodified-Since以時間為值，而If-Match以ETag為值。
簡而言之：If-Match跟If-None-Match與ETag的關系，就如同If-Unmodified-Since跟If-Modified-Since與Last-Modified的關系一樣。
- If-Modified-Since
類型：請求報頭。
重要程度：非常高。
這個請求報頭是支持條件HTTP GET的關鍵。客戶端把通過一次對同一URI的請求得到的Last-Modified的響應報頭的值，放在本次請求的If-Modified-Since報頭里。服務器可以根據比較If-Modified-Since的值與資源的最后更新日期，判斷來自客戶端上次請求以來資源有沒有發生過改變。若資源已發生改變。也就是說條件If-Modified-Since成立，那么服務器將把新的實體主體返回客戶端。若資源沒有發生改變，也就是說條件If-Modified-Since不成立，那么服務器將返回響應代碼304且不發送實體主體。
由於Last-Modified只能精確到1秒，所有有時僅靠If-Modified-Since會出現錯誤的結果。這就是為什么引入ETag與If-None-Match的原因。
- If-None-Match
類型：請求報頭。
重要程度：非常高。
這個報頭也用於支持條件HTTP GET。客戶端把通過前一次對同一URI請求得到的ETag響應報頭的值，放在本次請求的If-None-Match報頭里。若ETag自上次請求以來發生變化，
則條件If-None-Match成立，服務器把新的實體主體返回給客戶端。若ETag跟之前的一樣，則條件不成立，服務器返回響應代碼304，且不發送實體主體。
- If-Range
類型：請求報頭。
重要程度：低。
此報頭用於支持條件部分GET。 客戶端把通過前一次請求得到的ETag或Last-Modified響應報頭的值，放在本次請求的If-Range報頭里。假如客戶端請求的那部分表示已經變化，那么服務器就返回新的范圍。否則，服務器就返回響應代碼304，即便表示的其他地方發生了改變。
- If-Unmodified-Since
類型：請求報頭。
重要程度：中等。
正常情況下，客戶端把Last-Modified響應報頭的值作為If-Modified-Since請求報頭的值，以進行條件GET。這個報頭也采用Last-Modified響應報頭的值，但它常用於給除GET以外的HTTP動作施加條件。
舉個例子：包括你在內的很多人都想修改某個資源。你獲取該資源的表示，修改它，然后再用PUT請求把它發回去。但假如在發送PUT請求之前，該資源剛好被其他人修改了，
那么要么得到409，要么用你的修改把別人的修改覆蓋掉。
若發送上述PUT請求時通過If-Unmodified-Since施加條件，那么如果其他人修改了該資源的話，你將得到響應代碼417。你可以重新獲取表示，然后修改。
該報頭也可用於GET請求。
- Last-Modified
類型：響應報頭。
重要程度：非常高。
此報頭用於支持條件HTTP GET。它把表示的最后修改時間告訴客戶端。客戶端可以保存這個值，並在將來發送請求時給If-Modified-Since請求報頭設置這個值。
在web應用中，Last-Modified通常取當前時間，這使得條件HTTP GET無法發揮作用。web服務器應力圖做的更好一些，因為web服務器客戶端常會為同一URI反復請求服務器。
- Location
類型：響應報頭。
重要程度：非常高。
這是一個多功能的通用報頭。它跟3XX系列（重定向）響應代碼關系密切，而且很多關於HTTP重定向的混亂都源自對這個報頭的錯誤理解。
這個報頭告訴客戶端應該向哪個URI請求資源，假定客戶端原先不知道。也許，客戶端的請求導致該資源被創建或導致該資源的URI發生變化。也許，客戶端使用的是一個資源的舊URI，雖然該URI已不對應任何資源，但服務器還認識它。在這種情況下，響應代碼可以是301，也可以是307或302。
有時，Location報頭只是給出一個默認URI，比如用於300響應。有時，Location報頭的URI不是指向客戶端試圖訪問的資源，而是指向某個其他提供補充信息的資源，比如用於303響應。
- Max-Forwards
類型：請求報頭。
重要程度：非常低。
這個報頭主要跟TRACE方法配合使用。TRACE方法用於追蹤處理客戶端HTTP請求的代理。
- Pragma
類型：請求/響應報頭。
重要程度：非常低。
此報頭用於在客戶端、服務器及媒介（如代理）間傳達特殊指令。唯一一個官方指定是“no-cache”。不過它在HTTP 1.1中已經不使用了。可以通過Cache-Control報頭設置為“no-cache”起到同樣的作用。
- Proxy-Authenticate
類型：響應報頭。
重要程度：低到中等。
有些客戶端只能通過代理服務器來訪問外部web，有些代理服務器需要認證。這個報頭就是代理服務器提出認證要求的一種方式。這個報頭隨響應代碼407一起發送。它有跟WWW-Authenticate一樣的工作方式，只不過Proxy-Authenticate是代理提出認證要求，而WWW-Authenticate是web服務器提出認證要求，Proxy-Authenticate響應報頭跟Proxy-Authorization請求報頭相對，而WWW-Authenticate跟Authrization請求報頭相對。一個請求可能需要同時提供Authorization和Proxy-Authorization報頭。
- Proxy-Authorization
類型：請求報頭。
重要程度：低到中等。
此報頭用於通過一個要求認證的代理來發送請求。它和Authorization的工作方式類似。該報頭的格式依賴於Proxy-Authenticate。
- Range
類型：請求報頭。
重要程度：中等。
這個報頭表明客戶端試圖請求一個資源的部分表示。客戶端發送這個報頭，一般是因為之前在下載一個大型表示的過程中中斷了，現在，它回來繼續下載該表示的其余部分。
此報頭通常跟If-Unmodified-Since報頭一起使用。假如表示自從上次請求之后發生了改變，你很可能需要重新獲取整個表示。
- Referer
類型：請求報頭。
重要程度：低。
當在web瀏覽器里點擊一個鏈接時，瀏覽器將發出一個HTTP請求，而此請求的Referer報頭的值就是剛剛所處那個頁面的URI。
- Retry-After
類型：響應報頭。
重要程度：低到中等。
這個報頭通常與代表失敗的響應報頭一起使用，比如說413或某個5XX響應代碼。它告訴客戶端：雖然服務器目前無法處理你的請求，但也許一段時間之后就可以了。這個報頭的值是一個時間或秒數，客戶端可以在這個時間或秒數之后重試。
若服務器為每一個Retry-After報頭按同樣的規則來設置值得話，這只能使各個請求按原來的次序一一遲點到來--客戶端仍將一遍遍地重復收到Retry-After報頭。服務器應該采取某種隨機機制來改變Retry-After報頭，就像以太網的沖突回退周期一樣。
- TE
類型：響應報頭。
重要程度：低。
這個另一個“Accept”型報頭。客戶端通過這個報頭指定它將接受的傳送編碼。
在實際使用中，TE只被用於傳達“客戶端是否理解分塊編碼(chunked encoding)與HTTP報尾”這一信息。
- Trailer
類型：響應報頭。
重要程度：低。
當服務器采用分塊傳輸編碼（chunked transfer encoding）來發送實體主體時。它可以在實體主體的最后附加一些HTTP報頭，使它們由報頭成為“報尾”。服務器再把報頭作為報尾發送時，需要把這些報頭的名稱列在Trailer報頭里。
例如：Trailer：Content-Length
在服務器傳送完實體主體后，它會在實體主體之后附加一個Content-Length報尾，並給出實體主體的字節數。
- Transfer-Encoding
類型：響應報頭。
重要程度：低。
有時，服務器需要在尚不了解實體主體的某些重要方面的情況下發送該實體主體。服務器可以一塊一塊地傳送該實體主體，並把Content-Length等報頭放在實體主體之后。待所有塊都傳送結束后，服務器便可知道先前所不知道的一些信息了，它還可以把這些信息（如Content-Length和Content-MD5）作為“報尾”發送給客戶端。
- Upgrade
類型：請求報頭。
重要程度：非常低。
如果客戶端希望使用除HTTP以外的另一種協議，它可以通過Upgrade報頭通知服務器。若服務器剛好支持哪個協議，它將返回響應代碼101，並立即切換到新的協議。
本報頭的值不存在標准格式，但RFC2616里的Upgrade報頭示例反映了HTTP設計者的一些構想：
Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/X11
- User-Agent
類型：請求報頭。
重要程度：高。
服務器可以通過這個報頭知道發送請求的是在哪種客戶端軟件。在humen web上，這是一個表示web瀏覽器品牌的字符串。而在programmable web上，它通常標識用來編寫
客戶端的HTTP庫或者客戶端庫。
在human web 流行起來不久，服務器就開始通過User-Agent來了解對方是哪一種瀏覽器了，服務器會為不同的瀏覽器返回不同的表示。但根據User-Agent來發送不同的表示是一個槽糕的做法。檢測User-Agent不但已經造成各種web瀏覽器之間的不兼容，還導致了User-Agent報頭內部競爭。
幾乎現在所有的瀏覽器都冒充Mozilla，因為它是第一個流行的web瀏覽器的內部代碼名稱。若不冒充為Mozilla，瀏覽器可能得不到它想要的表示。由的瀏覽器不但冒充Mozilla，還冒充MSIE，以便能夠獲得針對目前最流行的web瀏覽器（IE）的表示，少數瀏覽器甚至允許用戶自行選擇User-Agent，以欺騙服務器發送響應的表示。
不要讓這種情況發生，web服務應該只通過User-Agent來收集統計數據並拒絕實現不佳的客戶端的訪問，而不應利用User-Agent來返回不同的表示。
- Vary
類型：響應報頭。
重要程度：低到中等。
此報頭用於告訴客戶端，它可以修改哪些請求報頭以得到一個資源的不同表示。如：Vary: Accept Accept-Language
該報頭的另一個作用是告訴緩存服務器“請把資源的日文與英文表示區分開緩存”。若Vary報頭的值為“*”，則表明響應不應被緩存。
- Via
類型：請求/響應報頭。
重要程度：低。
在一個HTTP請求直接從客戶端發往服務器、或一個響應直接從服務器發往客戶端時，是沒有Via報頭的，當途中存在媒介（如代理）時，每個代理都會在請求或響應消息上附加一個Via報頭，這樣，收到該消息的接收者就可以通過查看Via報頭來了解該HTTP消息經過了哪些媒介。
- Warning
類型：響應報頭。
重要程度：低。
Warning報頭是HTTP響應代碼的補充。媒介（如緩存代理）通過插入這個報頭，以告訴客戶端可能存在的，不可能從響應中明顯看出的問題。
跟響應代碼一樣，每個HTTP Warning報頭都有一個3位數的值 -- “警告代碼”。絕大多數警告跟緩存行為有關。如：
Warning:110 localhost:9090 Response is statle
意思是說：位於localhost:9090的緩存代理發送的是一個緩存的響應，雖然它知道該響應已經過期了。
- WWW-Authenticate
類型：響應報頭。
重要程度：非常高。
這個響應代碼是配合響應代碼401使用的。服務器通過這個報頭通知客戶端，它要求客戶端重新請求該URI並提供認證信息。它同時告訴客戶端服務器期望采用何種認證方案。
例如：HTTP 基本認證，HTTP摘要認證，或者Digest auth或WSSE。
非標准報頭
- Cookie
類型：請求報頭。
重要程度：在human web上高，在pragrammable web上低。
這可能是第二著名的HTTP報頭，但是它不屬於HTTP標准的一部分，他是Netscape的一個擴展。
cookie是客戶端與服務器之間的一個約定，即服務器通過Set-Cookie報頭在客戶單保存一些半持久化的狀態。每當客戶端得到一個cookie，它就應該在其后的每一個HTTP請求中附上這個cookie。客戶端正是通過Cookie報頭來傳送它的所有cookie的。因為這些通過HTTP報頭傳送的數據不可見，隨意仿佛客戶端與服務器在共享一些狀態。
在REST環境中，cookie的名聲並不好，原因有兩個，首先，它們包含“狀態”常常只是一個回話ID（seesionId），它破壞了無狀態性原則。第二，每當客戶端接受一個cookie，它就要為其后的每個請求都附上該cookie，這就意味着，客戶端不能再發送之前那些不包含cookie的請求，這也違反了無狀態性原則。
如果你必須使用cookie，那么請確保你在客戶端保存所有狀態。否則REST的可伸縮性優點將大打折扣。
- Set-Cookie
類型：響應報頭。
重要程度：在human web上高，在pragrammable web上低。
服務器通過這個報頭試圖在客戶端的cookie中保存一些半持久化的狀態。客戶端應該為其后的每一請求都附帶上這個cookie，直至該cookie過期。客戶端可以忽略此報頭，不為其后的請求設置Cookie報頭，但這樣做有可能得不到正確的響應。
- Slug
類型：請求報頭。
重要程度：相當重要，但僅限於APP應用
Slug報頭是Atom發布協議（Atom Publishing Protocol， APP）定義的，客戶端在向一個集合POST二進制文檔時，通過Slug報頭為這個二進制文檔設置標題。
關於自定義報頭設計原則
自定義報頭是最常見的一種擴展HTTP的方式，只要客戶端與服務器就報頭的含義達成一致，就可以隨請求或響應發送任何希望發送的信息。
指導原則如下：
- 不要重新發明已存在的報頭。
- 不要把本應放在實體主體里的信息放在報頭里。
- 應遵守命名慣例。自定義報頭的名稱應以“X-”開頭，這里“X”是“擴展（extension）”的意思。這樣命名可以明確分辨一個報頭是不是自定義報頭，而且避免與未來的官方HTTP報頭沖突。