http頭部 Expect
阿新 • • 發佈：2017-12-14
post cor 直接 body 服務 http post請求 服務器 數據
本文同時發表在https://github.com/zhangyachen/zhangyachen.github.io/issues/90
在通過curl調用對方接口時，發現超時現象很嚴重，於是詢問對方接口人，對方說需要加上：
curl_setopt($ch, CURLOPT_HTTPHEADER, array(‘Expect:‘));
加上之後發現果然好使了，於是調研了一下該用法。
在使用curl做POST的時候, 當要POST的數據大於1024字節的時候, curl並不會直接就發起POST請求, 而是會分為2個步驟：
- 發送一個請求, 包含一個Expect:100-continue, 詢問Server使用願意接受數據
- 接收到Server返回的100-continue應答以後, 才把數據POST給Server
但是這樣會有幾個問題：
- 不是所有的服務器都會正確應答100-continue, 比如lighttpd, 就會返回417 Expectation Failed。
- 造成延時，客戶端在發送第一次的Expect:100-continue時，需要等待服務器端進行回答之後才發送request body。
如果確定對方的服務器不會拒絕1024個字節以上的POST請求，就可以不使用該方法而且也可以避免以上提到的兩個副作用，解決的辦法就是文章開頭提到的。
關於100 continue
收到了請求的初始部分，請客戶端繼續。
這樣做的目的是：它可以讓客戶端在發送請求數據之前去判斷服務器是否願意接收該數據，如果服務器願意接收，客戶端才會真正發送數據，如果客戶端直接發送請求數據，但是服務器又將該請求拒絕的話，這種行為將帶來很大的資源開銷。
客戶端行為
發送了100 continue的客戶端不應該永遠等待服務器端做出回應，超時一段時間之後，客戶端應該直接將實體發送出去。
服務器端行為
如果服務器端收到了100 continue的請求，它會用100 continue響應或者發送一個錯誤碼。服務端永遠不能向沒有發送100 continue的客戶端發送100 continue。但是有的服務器會這麽做。IIS 5 incorrectly sending 100-continue response
如果服務端在還沒發送100 continue響應時就收到了客戶端的body，那麽說明客戶端決定開始發送數據了，所以此時服務器端不能再向客戶端發送100 continue。
參考資料：Expect:100-continue
http權威指南3.4.1
http頭部 Expect