先列出 HessianPHP 的错误提示: php
CURL transport error: transfer closed with outstanding read data remaining html
基础知识背景:
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 年撰文所写的: web
在使用 curl 作 POST 的时候,当要 POST 的数据大于 1024 字节的时候,curl 并不会直接就发起 POST 请求,而是会分为两步:
1. 发送一个请求,包含一个 "Expect: 100-continue" 头域,询问 Server 是否愿意接收数据;
2. 接收到 Server 返回的 100-continue 应答之后,才把数据 POST 给 Server;
这是 libcurl 的行为。
第一,libcurl 在发送大于 1024 字节的 POST 请求时采用了这种方法,可是相对的,它会引发请求延迟的加大。 服务器
第二,并非全部的 web server 都能正确处理并应答“100-continue”,好比 lighttpd,就会返回417”
Expectation Failed
“,形成请求逻辑出错。
郑昀注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。
调用接口时所传参数在某种极端条件下,
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 问题,但这只是工程师不肯意搞清楚原理而示弱的表现。
参考资源:
赠图几枚:
请施主拿去:
360度后空翻开球:
360无死角: