curl 在專案中使用頻率較高，比如內部介面、第三方 api、儲存服務等，但是我們在使用 curl 時可能並沒有注意到 expect 這個請求頭資訊，而 expect 設定不正確，會導致不必要的一次 http 請求，甚至可能會導致業務邏輯錯誤。
在不設定expect頭資訊使用 curl 傳送 post 請求時，如果 post 資料大於1kb，curl 預設行為 如下：
先追加乙個expect: 100-continue請求頭資訊，傳送這個不包含 post 資料的請求；
如果伺服器返回的響應頭資訊中包含expect: 100-continue，則表示 server 願意接受資料，這時才 post 真正資料給 server；
通過 tcpdump 工具抓包 curl 客戶端網路請求。檢視 http 請求響應頭以及資料：
$ tcpdump -a -s 0 'tcp port 80 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - ((tcp[12]&0xf0)>>2)) != 0)'請求資訊內容：
響應資訊：
可見此時，curl 傳送了一次不必要的 http 請求，從系統效能上來說這是不允許的。另外，並不是所有的 server 都會正確響應100-continue，反而會返回417 expectation failed，curl 端不會發起資料 post 請求，則會造成業務邏輯錯誤，我們應該避免這種情況的發生。
如果檢視過一些開源類庫（guzzle、qq第三方api，不過 solarium 並未支援），你就會發現他們在 curl 時已經注意到並解決這個問題了，只需 設定 expect 請求頭為空 即可。
// qq第三方api
// guzzle的curl adapter
if (!$request->hasheader('expect'))
再次 tcpdump 抓包，發現使用 curl 傳送超過 1kb 的 post 資料時，也並未出現 100-continue 的 http 請求。
expect 互動時 管道符的問題
今天同事說expect互動出了問題,無法呼叫gzip解壓匯入資料庫,但是手動執行卻沒問題 先來看看問題 usr bin expect set timeout 10000 spawn zcat db xd 20220208 133003.sql.gz mysql u xd p xd expect re...
curl在請求https的鏈結時的處理
curl在請求https的鏈結時的處理 1 不驗證證書和host curl setopt ch,curlopt ssl verifypeer,false curl setopt ch,curlopt ssl verifyhost,false 2 設定乙個正確的證書。放到 程式檔案目錄 curl 增加...
Linux安全必做的幾個設定
安全無小事，在這個系列中，我們會討論一些阻止黑客入侵你的系統的重要資訊，也可以 這個免費的網路點播研討會獲取更多的資訊。今天我們介紹了兩種方法阻止黑客入侵你的linux系統。如果你沒有在使用安全 shell，請應該使用它。使用ssh已經是乙個老話題了，telnet 是不安全的，rlogin 是不安全...