http 常見的request 請求頭,response 響應頭,常見的http狀態碼
request 請求頭
1.Host (主機和埠號)
Host:對應網址URL中的Web名稱和埠號,用於指定被請求資源的Internet主機和埠號,通常屬於URL的一部分。
2.Connection (連結型別)
Connection:表示客戶端與服務連線型別
Client 發起一個包含 Connection:keep-alive 的請求,HTTP/1.1使用 keep-alive 為預設值。
Connection 頭(header) 決定當前的事務完成後,是否會關閉網路連線。如果該值是“keep-alive”,網路連線就是持久的,不會關閉,使得對同一個伺服器的請求可以繼續在該連線上完成。
3. Server收到請求後
如果 Server 支援 keep-alive,回覆一個包含 Connection:keep-alive 的響應,不關閉連線;
如果 Server 不支援 keep-alive,回覆一個包含 Connection:close 的響應,關閉連線。
如果client收到包含 Connection:keep-alive 的響應,向同一個連線傳送下一個請求,直到一方主動關閉連線。
keep-alive在很多情況下能夠重用連線,減少資源消耗,縮短響應時間,比如當瀏覽器需要多個檔案時(比如一個HTML檔案和相關的圖形檔案),不需要每次都去請求建立連線。
4. Upgrade-Insecure-Requests (升級為HTTPS請求)
Upgrade-Insecure-Requests:升級不安全的請求,意思是會在載入 http 資源時自動替換成 https 請求,讓瀏覽器不再顯示https頁面中的http請求警報。
HTTPS 是以安全為目標的 HTTP 通道,所以在 HTTPS 承載的頁面上不允許出現 HTTP 請求,一旦出現就是提示或報錯。
如果在https的頁面需要載入http的資源,那麼瀏覽器就會報錯或者提示,為了促進使用者升級協議,同時不需要網站開發者勞師動眾地把整個網站的http資源改成https資源,chrome增加一個Upgrade-Insecure-Requests:1頭,告訴伺服器,瀏覽器可以處理https協議,然後伺服器返回Content-Security-Policy:upgrade-insecure-requests頭,或者通過meta頭設定,告訴瀏覽器,對於頁面的http資源,請求時可以自動升級到https,比如在https的網站上有一張圖片url是http://localhost/1.jpg,瀏覽器請求時會把url變成https://localhost/1.jpg,所以這裡首先需要伺服器在端有相對應的資源。但是有一種情況例外,那就是https網站中a標籤對應的外站資源不會被升級,比如a網站有一張b網站的連結,那麼這個連結對應的url不會升級。
5.User-Agent (瀏覽器名稱)--重要
User-Agent:是客戶瀏覽器的名稱,代表瀏覽器身份,有些時候同樣的網站使用不同瀏覽器訪問返回的資料會不一樣。
6.Accept (傳輸檔案型別)
Accept的作用
Accept:指瀏覽器或其他客戶端可以接受的MIME(MultipurposeInternet Mail Extensions(多用途網際網路郵件擴充套件))檔案型別,伺服器可以根據它判斷並返回適當的檔案格式。
舉例:
Accept: */*:表示什麼都可以接收。
Accept:image/gif:表明客戶端希望接受GIF影象格式的資源;
Accept:text/html:表明客戶端希望接受html文字。
Accept: text/html, application/xhtml+xml;q=0.9,image/*;q=0.8:表示瀏覽器支援的 MIME 型別分別是 html文字、xhtml和xml文件、所有的影象格式資源。
q是權重係數,範圍 0 =< q <= 1,q 值越大,請求越傾向於獲得其“;”之前的型別表示的內容。若沒有指定q值,則預設為1,按從左到右排序順序;若被賦值為0,則用於表示瀏覽器不接受此內容型別。
text:用於標準化地表示的文字資訊,文字訊息可以是多種字符集和或者多種格式的;application:用於傳輸應用程式資料或者二進位制數據。
7.Referer (頁面跳轉處)
Referer:表明產生請求的網頁來自於哪個URL,使用者是從該 Referer頁面訪問到當前請求的頁面。這個屬性可以用來跟蹤Web請求來自哪個頁面,是從什麼網站來的等。
有時候遇到下載某網站圖片,需要對應的referer,否則無法下載圖片,那是因為人家做了防盜鏈,原理就是根據referer去判斷是否是本網站的地址,如果不是,則拒絕,如果是,就可以下載;
8.Accept-Encoding(檔案編解碼格式)
Accept-Encoding:指出瀏覽器可以接受的編碼方式。編碼方式不同於檔案格式,它是為了壓縮檔案並加速檔案傳遞速度。瀏覽器在接收到Web響應之後先解碼,然後再檢查檔案格式,許多情形下這可以減少大量的下載時間。
舉例:Accept-Encoding:gzip;q=1.0,identity; q=0.5, *;q=0
如果有多個Encoding同時匹配, 按照q值順序排列,本例中按順序支援gzip, identity壓縮編碼,支援gzip的瀏覽器會返回經過gzip編碼的HTML頁面。 如果請求訊息中沒有設定這個域伺服器假定客戶端對各種內容編碼都可以接受。
9. Accept-Language(語言種類)
Accept-Langeuage:指出瀏覽器可以接受的語言種類,如en或en-us指英語,zh或者zh-cn指中文,當伺服器能夠提供一種以上的語言版本時要用到。
10. Accept-Charset(字元編碼)
Accept-Charset:指出瀏覽器可以接受的字元編碼。
舉例:Accept-Charset:iso-8859-1,gb2312,utf-8
· ISO8859-1:通常叫做Latin-1。Latin-1包括了書寫所有西方歐洲語言不可缺少的附加字元,英文瀏覽器的預設值是ISO-8859-1.
· gb2312:標準簡體中文字符集;
· utf-8:UNICODE 的一種變長字元編碼,可以解決多種語言文字顯示問題,從而實現應用國際化和本地化。
如果在請求訊息中沒有設定這個域,預設是任何字符集都可以接受。
GB2312 <GBK < GB18030
11.Cookie (Cookie)--重要
Cookie:瀏覽器用這個屬性向伺服器傳送Cookie。Cookie是在瀏覽器中寄存的小型資料體,它可以記載和伺服器相關的使用者資訊,也可以用來實現會話功能,以後會詳細講。
12.Content-Type (POST資料型別)
Content-Type:POST請求裡用來表示的內容型別。
舉例:Content-Type = Text/XML; charset=gb2312:
指明該請求的訊息體中包含的是純文字的XML型別的資料,字元編碼採用“gb2312”。
response 請求頭
1.Cache-Control:must-revalidate,no-cache, private
這個值告訴客戶端,服務端不希望客戶端快取資源,在下次請求資源時,必須要從新請求伺服器,不能從快取副本中獲取資源。
Cache-Control是響應頭中很重要的資訊,當客戶端請求頭中包含Cache-Control:max-age=0請求,明確表示不會快取伺服器資源時,Cache-Control作為作為迴應資訊,通常會返回no-cache,意思就是說,"那就不快取唄"。
當客戶端在請求頭中沒有包含Cache-Control時,服務端往往會定,不同的資源不同的快取策略,比如說oschina在快取圖片資源的策略就是Cache-Control:max-age=86400,這個意思是,從當前時間開始,在86400秒的時間內,客戶端可以直接從快取副本中讀取資源,而不需要向伺服器請求。
2.Connection:keep-alive
這個欄位作為迴應客戶端的Connection:keep-alive,告訴客戶端伺服器的tcp連線也是一個長連線,客戶端可以繼續使用這個tcp連線傳送http請求。
3.Content-Encoding:gzip
告訴客戶端,服務端傳送的資源是採用gzip編碼的,客戶端看到這個資訊後,應該採用gzip對資源進行解碼。
4.Content-Type:text/html;charset=UTF-8
告訴客戶端,資原始檔的型別,還有字元編碼,客戶端通過utf-8對資源進行解碼,然後對資源進行html解析。通常我們會看到有些網站是亂碼的,往往就是伺服器端沒有返回正確的編碼。
5.Date: Tue, 03 Apr 2018 03:52:28 GMT
這個是服務端傳送資源時的伺服器時間,GMT是格林尼治所在地的標準時間。http協議中傳送的時間都是GMT的,這主要是解決在網際網路上,不同時區在相互請求資源的時候,時間混亂問題。
6.Expires:Sun, 1 Jan 2000 01:00:00 GMT
這個響應頭也是跟快取有關的,告訴客戶端在這個時間前,可以直接訪問快取副本,很顯然這個值會存在問題,因為客戶端和伺服器的時間不一定會都是相同的,如果時間不同就會導致問題。所以這個響應頭是沒有Cache-Control:max-age=*這個響應頭準確的,因為max-age=date中的date是個相對時間,不僅更好理解,也更準確。
7.Pragma:no-cache
這個含義與Cache-Control等同。
8.Server:Tengine/1.4.6
這個是伺服器和相對應的版本,只是告訴客戶端伺服器的資訊。
9.Transfer-Encoding:chunked
這個響應頭告訴客戶端,伺服器傳送的資源的方式是分塊傳送的。一般分塊傳送的資源都是伺服器動態生成的,在傳送時還不知道傳送資源的大小,所以採用分塊傳送,每一塊都是獨立的,獨立的塊都能標示自己的長度,最後一塊是0長度的,當客戶端讀到這個0長度的塊時,就可以確定資源已經傳輸完了。
10.Vary: Accept-Encoding
告訴快取伺服器,快取壓縮檔案和非壓縮檔案兩個版本,現在這個欄位用處並不大,因為現在的瀏覽器都是支援壓縮的。
常見的http狀態碼
100 | 客戶端可以繼續 |
101 | 指示伺服器正根據 Upgrade 頭切換協議 |
200 | 請求正常成功 |
201 | 指示請求成功並在伺服器上建立了一個新資源 |
202 | 指示已接受請求進行處理但處理尚未完成 |
203 | 指示客戶端呈現的元資訊並不源自伺服器 |
204 | 指示請求成功但沒有返回新資訊 |
205 | 指示代理應該 重置導致請求被髮送的文件檢視 |
206 | 指示伺服器已完成對資源的部分 GET 請求 |
300 | 請求的資源對應於表示形式集合中的某種表示形式,每種表示形式都有自己的特定位置 |
301 | 指示已經將資源永久地移動到了某個新位置,並且將來的引用應將新 URI 用於其請求 |
302 | 指示已經將資源暫時地移動到了另一個位置,但將來的引用仍應使用原來的 URI 訪問該資源。 保留此定義是為了向後相容。SC_FOUND 現在是首選定義 |
303 | 指示可在另一個 URI 之下找到該請求的響應 |
304 | 指示條件 GET 操作發現資源可用但不可修改 |
305 | 指示必須 通過 Location 欄位給定的代理訪問請求資源 |
307 | 指示請求的資源暫時駐留在另一個 URI 之下。臨時 URI 應該 通過響應中的 Location 欄位提供 |
400 | 指示客戶端傳送的請求在語法上不正確 |
401 | 指示請求需要進行 HTTP 驗證 |
402 | 保留此程式碼以備將來使用 |
403 | 指示伺服器理解請求但拒絕完成它 |
404 | 指示請求的資源不可用 |
405 | 指示 Request-Line 中指定的方法不支援 Request-URI 標識的資源 |
406 | 指示請求標識的資源只能生成響應實體,根據請求中傳送的 accept 頭,這些響應實體具有不可接受的內容特徵 |
407 | 指示客戶端必須 首先通過代理驗證其自身 |
408 | 指示客戶端沒有在伺服器準備等待的時間內生成請求 |
409 | 指示由於與當前資源狀態衝突請求無法完成 |
410 | 指示資源在伺服器上不再可用並且不知道轉發地址。應該 認為此條件是永久性的 |
411 | 指示在沒有定義 Content-Length 的情況下無法處理請求 |
412 | 指示在伺服器上測試一個或多個請求頭欄位中給出的前提時,該前提被求值為 false |
413 | 指示因為請求實體大於伺服器願意或能夠處理的實體,所以伺服器拒絕處理請求 |
414 | 指示因為 Request-URI 的長度大於伺服器願意解釋的 Request-URI 長度,所以伺服器拒絕為請求提供服務 |
415 | 指示因為請求實體的格式不受請求方法的請求資源支援,所以伺服器拒絕為請求提供服務 |
416 | 指示伺服器無法服務於請求的位元組範圍 |
417 | 指示伺服器無法服務於請求的位元組範圍 |
500 | 指示 HTTP 伺服器記憶體在錯誤使伺服器無法完成請求 |
501 | 指示 HTTP 伺服器不支援完成請求所需的功能 |
502 | 指示 HTTP 伺服器在充當代理或閘道器時從它參考的伺服器接收到一個無效響應 |
503 | 指示 HTTP 伺服器暫時過載,並且無法處理請求 |
504 | 指示伺服器在充當閘道器或代理時沒有從上游伺服器接收到及時的響應 |
505 | 指示伺服器不支援或拒絕支援請求訊息中使用的 HTTP 協議版本 |