先列出 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‘特性：
1. 发送一个请求，包含一个 expect: 100-continue 头域，询问 server 是否愿意接收数据；2. 接收到 server 返回的 100-continue 应答以后，才把数据 post 给 server； 
    zxgfa 在 2012年补充说：
（郑昀注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头域：        
图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 报错“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:) 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无死角：
http://www.bkjia.com/phpjc/440146.htmlwww.bkjia.comtruehttp://www.bkjia.com/phpjc/440146.htmltecharticle先列出 hessianphp 的错误提示： 基础知识背景： 1）expect: 100-continue的来龙去脉： http/1.1 协议里设计100 (continue) http 状态码的的目的是，在客...