RCA：未注意Curl-library Post 1024以上字節時的HTTP/1.1特性導致 HessianPHP 傳

先列出 HessianPHP 的錯誤提示：

---

基礎知識背景： 1）“Expect: 100-continue”的來龍去脈：     HTTP/1.1 協議裡設計 100 (Continue) HTTP 狀態碼的的目的是，在客戶端發送 Request Message 之前，HTTP/1.1 協議允許客戶端先判定服務器是否願意接受客戶端發來的消息主體（基於 Request Headers）。     即，Client 和 Server 在 Post （較大）數據之前，允許雙方“握手”，如果匹配上了，Client 才開始發送（較大）數據。     這麼做的原因是，如果客戶端直接發送請求數據，但是服務器又將該請求拒絕的話，這種行為將帶來很大的資源開銷。       協議對 HTTP/1.1 clients 的要求是：

2）libcurl 發送大於1024字節數據時啟用“Expect:100-continue‘特性：

2. 接收到 Server 返回的 100-continue 應答以後，才把數據 POST 給 Server；

 

    zxgfa 在 2012年補充說：

 

3）PHP Curl-library 可以主動封禁此特性：     有人在 PHP手冊::curl_setopt 下留言說：     PHP curl 遵從 libcurl 的特性。由於不是所有 web servers 都支持這個特性，所以會產生各種各樣的錯誤。如果你遇到了，可以用下面的命令封禁"Expect"頭域：         <?php     curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:'));
    ?>

        圖1 You can convince PHP's curl backend to stop doing the 100-continue-thing by setting an explicit request header  

---

其他知識背景：

• 根據 HessianTransport 代碼所述，”Hessian request using the CURL library“。

---

問題現象：

  解決： 修改hessian中 CURLOPT 項： CURLOPT_HTTPHEADER => array("Content-Type: application/binary")  改為 CURLOPT_HTTPHEADER => array("Content-Type: application/binary","Expect:") 

---

p.s.:     有人認為改為 HTTP/1.0 協議即可繞過這個 100-continue 問題，但這只是工程師不願意搞清楚原理而示弱的表現。   參考資源： 1）2011，Laruence，Expect:100-continue； 2）PHP手冊，If you are doing a POST, and the content length is 1,025 or greater； 3）HTTP 1.1 RFC，Use of the 100 (Continue) Status； 4）stackoverflow，2009，PHP HTTP POST fails when cURL data > 1024； 5）zxgfa，2012，libcurl的使用問題“Expect100-continue”； 6）lighttpd，2009，'Expect' header gives HTTP error 417；

---

贈圖幾枚： 請施主拿去： 360度後空翻開球： 360無死角：