哈嘍大家好，我是鹹魚。今天給大家分享一個關於 HTTP 有趣的現象 鏈接：https://csvbase.com/meripaterson/stock-exchanges 我們用瀏覽器訪問這個鏈接，可以看到下麵的網頁 但如果我們使用 curl 命令去訪問這個鏈接呢？ 可以看到返回的是一個 csv 文 ...
哈嘍大家好，我是鹹魚。今天給大家分享一個關於 HTTP 有趣的現象
鏈接：https://csvbase.com/meripaterson/stock-exchanges
我們用瀏覽器訪問這個鏈接，可以看到下麵的網頁
但如果我們使用 curl 命令去訪問這個鏈接呢？
可以看到返回的是一個 csv 文件
我們用 wget 命令下載下來看看
可以看到 text/csv 欄位，表示下載了一個 csv 格式的文件
奇怪，同樣的 url ，為什麼瀏覽器返回的內容跟 curl、wget 命令返回的內容卻不一樣
內容協商
當 HTTP 客戶端去發送響應給 HTTP 服務端的時候，響應裡面會包含響應頭（headers）
我們來看下 Google瀏覽器發送的響應頭
我們著重註意一下響應頭裡的 accept 欄位
這個 accept 報頭是一個無序列表，它告訴了 HTTP 服務端應該返回什麼媒體類型（又稱內容類型或文件格式）的內容給我
以上面 Google 瀏覽器的 accept 報頭為例：這段 accept 報頭表示該請求中瀏覽器可接受的媒體類型（或文件格式）的偏好。從左到右，各類型的優先順序逐漸降低
text/html: 瀏覽器首選的媒體類型，即 HTML 文本。application/xhtml+xml: 次選的媒體類型，即 XHTML 文本。application/xml;q=0.9: 伺服器可以發送的 XML 類型的文本，但是客戶端更願意接收前面的兩種媒體類型，所以權重為 0.9。image/avif,image/webp,image/apng: 瀏覽器能夠接受的圖片類型，優先順序逐漸降低。如果伺服器返回多種可接受的圖片類型，則瀏覽器將選擇優先順序最高的那個。*/*;q=0.8: 如果伺服器無法以以上任何一種類型響應，則瀏覽器願意接受任何類型，但是這個類型的優先順序最低，只有 0.8。application/signed-exchange;v=b3;q=0.7: 該媒體類型是用於實現 Web 頁面“前進”和“後退”功能的標準。客戶端更願意接受前面提到的其他媒體類型，所以該類型的權重為 0.7。
所以說我們用 Google 瀏覽器去訪問這個 url （csvbase.com）時，會跟 HTTP 服務端去協商：你應該返回什麼類型的內容給我，優先是 text/html
而 curl 命令或者 wget 命令去訪問請求這個 url 時，預設情況下發送的請求頭中的 Accept 欄位的值是 */*，表示支持接受所有類型的響應
而這個網站 csvbase 預設格式是 csv，所以說當 curl 命令或者 wget 命令去訪問請求這個 url 時，得到的是一個 csv 格式返回內容
這就是 HTTP 協議中的內容協商（content negotiation）
HTTP內容協商是指客戶端和伺服器端協商出最適合的響應數據格式、語言等內容的過
HTTP中的內容協商機制，可以確保客戶端和伺服器端發送和接收的內容格式是一致的，從而提高通信的效率和可靠性
HTTP內容協商通常有三種類型：
- 基於請求頭的內容協商（Header-based content negotiation）
- 基於URL的內容協商（URL-based content negotiation）
- 基於實體的內容協商（Entity-based content negotiation）
基於請求頭的內容協商是指客戶端在請求頭中指定自己可以接受的內容類型（MIME類型），伺服器根據客戶端的請求頭中所指定的信息，選擇最合適的響應內容類型進行響應
常用的請求頭欄位是 Accept 和 Accept-Language。伺服器端根據 Accept 欄位的內容，選擇最匹配的響應類型進行響應
如果客戶端所能接受的響應類型都不能滿足伺服器端的響應類型，則會返回一個 406 Not Acceptable 的錯誤狀態碼
那有小伙伴可能會想：我用 curl 命令或者 wget 命令不想得到一個 csv 格式的響應，我想 HTTP 服務端返回其他類型的響應，這時候該怎麼辦
我們可以手動修改請求頭來告訴 HTTP 服務端它可以接受的媒體類型（即文件格式）的偏好
參考文章：
How does it know I want csv? — An HTTP trick (csvbase.com)
