目錄
3.Accept-Encoding&Content-Encoding
HTTP header概覽
本文主要關注報文首部字段（header field ），HTTP首部字段是由首部字段名和字段值構成的，中間用冒號“:”分隔，樣例如下
Content-Type: application/xml
Connection: Keep-alive
首部字段（header field ）按照使用方的維度可以分爲以下4類，具體某個header詳情參考文檔 和rfc2616
| 首部字段分類 | 含義 | 常用首部 |
|---|---|---|
| 通用 General | 請求和響應雙方都使用 |
Cache-Control、Connection、Date、Pragma、Trailer、Transfer-Encoding、Upgrade、Via、Warning |
| 通用實體Entity | 請求和響應的實體body部分使用 |
Allow Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type Expires、Last-Modified |
| 請求 Request | 客戶端發送請求時使用 |
Accept、Accept-Charset、Accept-Encoding、Accept-Language Authorization、Expect、From、Host If-Match、If-Modified-Since、If-None-Match、If-Range、If-Unmodified-Since Max-Forwards、Proxy-Authorization、Range、Referer、TE、User-Agent |
| 響應 Response | 服務端返回響應時使用 |
Accept-Ranges、Age、ETag、Location、Proxy-Authenticate、Retry-After、 Server、Vary、WWW-Authenticate |
還有Cookie、Set-Cookie和Content-Disposition等在其他RFC中定義的首部字段，它們的使用頻率也很高。
按照功能分類，藍色表請求頭，紫色表示響應頭，紅色表示通用頭
| 分類 | headers | 應用 |
|---|---|---|
| 緩存控制 |
|
緩存控制參考 |
| 內容協商 |
Accept、Accept-Charset、Accept-Encoding、Accept-Language Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type |
某一資源，服務端有多個版本， 客戶端告知服務器自己的偏好Accept， 服務器據偏好選擇對應版本響應客戶端的請求 |
| 連接管理 |
Connection Keep-Alive |
Keep-Alive複用tcp連接 close 每次重新建立連接 |
| 代理路徑 |
Via Max-Forwards |
Via: 1.1 ID-5301755340307730 uproxy-6 （http協議版本，代理服務器信息） Max-Forwards每經過跳-1， 0時代理服務器不能再轉發該請求了 |
| 條件請求 |
If-Match、If-None-Match、Etag If-Modified-Since、If-Unmodified-Since If-Range |
If-Match的值跟服務端ETag值匹配一致時， 服務端纔會接受請求 If-Modified-Since 客戶端緩存更新，如果在If-Modified-Since字段指定的日期時間後，資源發生了更新，服務器會接受請求 |
那些年用錯HTTP header的異象
1.Content-length
字段Content-Length表明了實體主體部分的大小（單位是字節）。對實體主體進行內容編碼傳輸時，不能再使用Content-Length首部字段。
項目中使用了Content-length字段，傳輸了報文體的字節長度，當時對端收到的報文少了一些字符。因爲Content-length小於實際報文長度，導致發生截斷。
解決方案，去掉該頭即可。具體請戳
2.Content-Type
當傳輸有交換格式的報文，如xml等不帶header（Content-Type:application/xml;charset=utf-8）的話，一般的http client實現發送時底層會對報文進行URLencode，對端收到的就是對特殊字符編碼後的樣子。
| client傳輸的報文 | Server收到的報文 |
|---|---|
| <?xml version="1.0" encoding="UTF-8"?> | %3c%3fxml+version%3d%221.0%22+encoding%3d%22UTF-8%22%3f%3e |
3.Accept-Encoding&Content-Encoding
客戶端頭部Accept-Encoding字段值爲空，則只有“ identity”編碼是可以接受的。
當客戶端傳輸Accept-Encoding: gzip時，服務端會傳輸gzip壓縮後的響應，但是客戶端如果不支持gzip解碼的話，還按照簡單的字節流處理方式，會報異常報文。
4.Connection
管理持久連接，http/1.1不傳默認好似Keep-Alive。
| 通用頭部header | 含義 |
|---|---|
| Connection: close |
當服務器端想明確斷開連接時，則指定Connection首部字段的值爲Close HTTP/1.1之前的HTTP版本的默認 |
| Connection:Keep-Alive |
在舊版本的HTTP協議上維持持續連接 HTTP/1.1版本的默認連接都是持久連接 |
HTTP/1.1版本的默認連接都是持久連接。爲此，客戶端會在持久連接上連續發送請求。當服務器端想明確斷開連接時，則指定Connection首部字段的值爲Close。
沒有配置這個字段，默認是Keep-Alive，客戶端會複用這個tcp連接，如果服務端斷開了連接，就會報通信異常，對端已經關閉了連接。
可以通過傳輸Connection: close 主動關閉連接（不再複用），避免後續請求的通信異常。
