先列出 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 年撰文所写的：
在使用 curl 做 POST 的时候，当要 POST 的数据大于 1024 字节的时候，curl 并不会直接就发起 POST 请求，而是会分为两步：1. 发送一个请求，包含一个 "Expect: 100-continue" 头域，询问 Server 是否愿意接收数据；2. 接收到 Server 返回的 100-continue 应答以后，才把数据 POST 给 Server；这是 libcurl 的行为。
zxgfa 在 2012年补充说：
第一，libcurl 在发送大于 1024 字节的 POST 请求时采用了这种方法，但是相对的，它会引起请求延迟的加大。
第二，并不是所有的 web server 都能正确处理并应答“100-continue”，比如 lighttpd，就会返回417” Expectation Failed “，造成请求逻辑出错。（ 注1：lighttpd ，于1.5版本修复。注2：Resin 于 3.0.5 版本增加了对 Expect: 100-continue 的支持。）
3）PHP Curl-library 可以主动封禁此特性：
有人在 下留言说：
PHP curl 遵从 libcurl 的特性。由于不是所有 web servers 都支持这个特性，所以会产生各种各样的错误。如果你遇到了，可以用下面的命令封禁"Expect"头域：
<?php curl_setopt($ch, CURLOPT_HTTPHEADER, array('Expect:')); ?> pooy示范代码如下所示： 图1 You can convince PHP's curl backend to stop doing the 100-continue-thing by setting an explicit request header
其他知识背景：
- 根据 所述，”Hessian request using the CURL library“。
问题现象：
通信协议是 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:")
p.s.:
有人认为改为 HTTP/1.0 协议即可绕过这个 100-continue 问题，但这只是工程师不愿意搞清楚原理而示弱的表现。
参考资源：
1）2011，Laruence， ；
2）PHP手册， ；
3）HTTP 1.1 RFC， ；
4）stackoverflow，2009， ；
5）zxgfa，2012， ；
6）lighttpd，2009， ；
赠图几枚：
请施主拿去：
360度后空翻开球：
360无死角：