標籤:style http color 使用 strong os
核心提示:先列出 HessianPHP 的錯誤提示: CURL transport error: transfer closed with outstanding read data remaining 基礎知識背景: 1)“Expect: 100-continue”的來龍去脈: HTTP/1.1 協議裡設計100 (Continue) HTTP 狀態代碼的的目的是,在客 ...
先列出 HessianPHP 的錯誤提示:
CURL transport error: transfer closed with outstanding read data remaining
基礎知識背景:
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 的要求是:
如果 client 預期等待“100-continue”的應答,那麼它發的請求必須包含一個 " Expect: 100-continue" 的頭域!
2)libcurl 發送大於1024位元組資料時啟用“Expect:100-continue‘特性:
這也就是 Laruence 在 2011 年撰文所寫的: 內容來自17jquery
在使用 curl 做 POST 的時候,當要 POST 的資料大於 1024 位元組的時候,curl 並不會直接就發起 POST 請求,而是會分為兩步:
1. 發送一個請求,包含一個 "Expect: 100-continue" 頭域,詢問 Server 是否願意接收資料;
2. 接收到 Server 返回的 100-continue 應答以後,才把資料 POST 給 Server; 這是 libcurl 的行為。
一起jquery,17jquery
zxgfa 在 2012年補充說:
第一,libcurl 在發送大於 1024 位元組的 POST 請求時採用了這種方法,但是相對的,它會引起請求延遲的加大。 第二,並不是所有的 web server 都能正確處理並應答“100-continue”,比如 lighttpd,就會返回417” Expectation Failed “,造成請求邏輯出錯。(鄭昀注1:lighttpd 1.4 版本有此嚴重問題,於1.5版本修複。 鄭昀注2:Resin 於 3.0.5 版本增加了對 Expect: 100-continue 的支援。)
3)PHP Curl-library 可以主動封鎖此特性: 有人在PHP手冊::curl_setopt下留言說: PHP curl 遵從 libcurl 的特性。由於不是所有 web servers 都支援這個特性,所以會產生各種各樣的錯誤。如果你遇到了,可以用下面的命令封鎖"Expect"頭域: <?php
curl_setopt($ch,CURLOPT_HTTPHEADER, array(‘Expect:‘));
?>
pooy示範代碼如下所示:
內容來自17jquery
圖1 You can convince PHP‘s curl backend to stop doing the 100-continue-thing by setting an explicit request header
其他知識背景:
問題現象:
通訊協定是 Hessian。 調用介面時所傳參數在某種極端條件下, POST 的資料長度超過 1024 位元組,hessian 報錯“CURL transport error: transfer closed with outstanding read data remaining”。
解決:修改hessian中 CURLOPT 項: CURLOPT_HTTPHEADER => array("Content-Type: application/binary") 改為 CURLOPT_HTTPHEADER => array("Content-Type: application/binary","Expect:")