這裡是我自學的過程，僅僅是為了輸出，如果能幫助到您那真的是太好了（文中自帶吐槽，如果有大佬能順便解釋疑惑那真的是更好了）
0x02 authorization
0x03 expect
0x04 from
0x05 host
0x06 if-***系列
0x07 max-forwards
0x08 range
0x09 referer
0x0a te
0x0b user-agent
總結這裡就是客戶端告訴伺服器，我可以接收啥東西，最好使用啥方式給我
向伺服器告知客戶端可以處理的**型別，使用type/subtype的形式，例如text/html的意思就是要求html格式的檔案，可以使用q=額外表示權重值，使用分號進行分割。權重值預設q=1.0，範圍是0-1，精確到小數點後3位。最優先返回權重值最高的型別。（《**http》騙我，102頁的內容有錯）*/*代表啥我都能接收。
告訴伺服器，客戶端提交的表單可能使用的編碼方式。（好像沒啥用）也可以使用q，但是這個q是幹啥的啊？這些有優先順序？
告訴伺服器，客戶端支援的的內容編碼（壓縮）以及優先順序（q），星號（*）表示接受任意編碼格式。（這裡可以寫各種格式的具體情況，但是我懶）
告訴伺服器，客戶端支援的自然語言集（例如中文，英文），同樣用q表示相對優先順序。
告知伺服器，客戶端的認證資訊。因為http協議是無狀態的，瀏覽器用cookie識別身份，桌面客戶端也用http協議與web伺服器互動，不用cookie，用http基本認證
c傳送請求報文給s
報文中沒有authorization，s返回乙個401 unauthozied給c，並在響應報文中www-authenticate中新增資訊
c把使用者名稱和密碼編碼後，放在authorization中發給s，認證成功
s將使用者名稱，密碼取出，進行驗證，如果通過，傳送資源給客戶端。
p.s:http無狀態，每個請求都要認證。
編碼後的string用程式很容易解密，所以一般用https傳輸，因為https是加密的。
我完全看不懂，希望以後能接解決（這個好像出現的很少，出現的話很可能是報錯，因為有些舊的協議不支援）。
我好像有些懂了，expect的域，是用於指出客戶端要求的特殊伺服器行為，如果伺服器不能理解或這滿足域中的任意一種值，必須返回417狀態（如果請求有其他問題，返回4xx狀態）。這個域使用擴充套件語法定義，方便未來的擴充套件。（剩下的內容看不太懂，以後再說）
這裡面有乙個特殊的：expect：100-continue,
expect:100-continue握手的目的，是為了允許客戶端在傳送請求內容之前，判斷源伺服器是否願意接受請求（基於請求頭部）。這個握手謹慎用，因為遇到不支援的伺服器或者**伺服器會引起問題
md，寫了這麼多，完全沒想到這個對於滲透測試的幫助，難道在攻擊的時候加上這個頭讓伺服器瘋狂報錯不成。
告訴伺服器，使用者的電子郵箱位址，emmm這個有啥用？
告訴伺服器，客戶端找的主機名（和埠號）。因為虛擬主機執行在同乙個ip上，用host加以區分。
條件請求，就像if語句一樣，伺服器接收到後，條件為真才會執行請求。
告訴伺服器資源的實體標記（etag）值（這個在後面會說，我現在也是有點懵）。這時伺服器無法使用弱etag值。伺服器會對比if-match的字段值和資源的值，兩者一致時才會執行請求，否則，返回412。如果if-match的值是*，只要資源存在，伺服器就會處理請求。
它會有乙個值（時間），伺服器將值與資源最後被修改的時間進行對比，如果資源在它的值之後更新了，就處理這個請求。
這個可以與客戶端的快取相配合使用，順便擴充套件到了實體頭部請求last-modified
last-modified：瀏覽器第一次請求某乙個uri時，伺服器端會返回200狀態，同時會標註乙個last-modifiied，用以標記此檔案在伺服器端最後被修改的時間。
if-modified-since：客戶端第二次請求同乙個uri時，會向伺服器端傳送if-modified-since報頭，標記的是本地瀏覽器儲存的檔案修改時間。（就是上次last-modified的值）
伺服器端檢查這個值，如果一樣，返回304狀態碼，客戶端接到後直接把本地快取顯示到瀏覽器中，節省了傳輸資料量；如果不一樣，返回200狀態碼和新的檔案內容
與if-match相反，值不同時才會執行。在get或head方法中可以請求最新的資源，與if-modified-since相似。
這個請求要與range和etge相搭配看，要不然就會很懵逼，我現在就是在懵逼，以後再補這個和前面那兩個請求的鏈結。
和if-modified-since相反，如果資源在它的值之後沒有更新，才會處理這個請求
通過trace方法或者options方法，傳送包含首部欄位max-forwards的請求時，它的值意味著可經過的伺服器最大數目，當伺服器（無論是源伺服器還是**伺服器）接收max-forwards的值為0的請求時，伺服器直接返回響應。（這樣可以防止莫名奇妙陷入**伺服器互相**的迴圈）
proxy-authorization：
與authorization類似，不過這個是告訴**伺服器認證資訊（proxy）
客戶端只想獲取部分資源，用range這個字段確認資源的範圍
例如：
range：bytes=5001-10000接收到這個請求的伺服器，處理請求後會返回206的狀態碼，如果無法處理，會返回200 ok和全部的資源
告知伺服器請求的原始資源的uri。
這樣做有點不太安全，因為原始資源的uri可能有id和密碼等資訊，寫進referer有洩露的可能。
它的正確拼寫好像是referrer，大家都在用這個錯誤的拼寫（我沒求證，寫著圖一樂）
告訴伺服器，客戶端可以處理響應的傳輸編碼方式和優先順序，（沒錯，又是q）
和accept-encoding很像，不過他是傳輸編碼
（我懷疑是transfer-encoding的縮寫，這玩意不是通用首部欄位嗎）
我真是個小機靈鬼，te和transfer-encoding的確很像，不過transfer-encoding規定的是傳輸報文主體時的編碼，這倆都是逐跳首部，只在兩個節點間起作用。
它可以指定伴隨trailer欄位的分塊傳輸編碼的方式:
te：trailers將建立請求的瀏覽器和使用者**名稱等資訊傳達給伺服器。
由網路爬蟲發起的請求，可能會在字段內新增爬蟲作者的電子郵箱位址。經過**伺服器，也有可能會新增**伺服器的名稱。
首部欄位就這些，以後學的更深入了，可能會回來更新在web滲透測試的應用場景。
Http協議 請求報文和響應報文
這相當於是一種規範,網路中資料的傳輸在位於應用之下的各層 傳輸層,應用層 來完成的,在tcp ip協議接收到資料時,我們是不能直接使用和瀏覽的,需要先通過一種規範來進行梳理,也就是解碼,得到瀏覽器支援的一種格式,才能被我們使用.在web開發中,熟悉http協議中的報文結構是很重要的,比如,如果對ht...
重溫Http協議 請求報文和響應報文
這相當於是一種規範,網路中資料的傳輸在位於應用之下的各層 傳輸層,應用層 來完成的,在tcp ip協議接收到資料時,我們是不能直接使用和瀏覽的,需要先通過一種規範來進行梳理,也就是解碼,得到瀏覽器支援的一種格式,才能被我們使用.在web開發中,熟悉http協議中的報文結構是很重要的,比如,如果對ht...
重溫Http協議 請求報文和響應報文
這相當於是一種規範,網路中資料的傳輸在位於應用之下的各層 傳輸層,應用層 來完成的,在tcp ip協議接收到資料時,我們是不能直接使用和瀏覽的,需要先通過一種規範來進行梳理,也就是解碼,得到瀏覽器支援的一種格式,才能被我們使用.在web開發中,熟悉http協議中的報文結構是很重要的,比如,如果對ht...