我使用cURL在两台服务器之间传输数据--两台服务器都运行Ubuntu 12.04、Lighttpd和PHP5.5 FastCGI。我曾经对数据进行bzcompress--这纯粹是一个遗留问题：我发现bzcompress在将文本数据写入文件时提供了更有效的压缩。传输的数据往往相当小-通常在512字节以下。
但是，今天我遇到了一个问题，因为数据有点长-接近1 kB。curl_exec适时地返回true，并且没有报告任何错误。但是，数据从未到达它们的目的地。我的原始代码如下
curl_setopt($ch,CURLOPT_URL,$url);
curl_setopt($ch,CURLOPT_POST,1);
curl_setopt($ch,CURLOPT_POSTFIELDS,"{$cql}");
curl_setopt($ch,CURLOPT_RETURNTRANSFER,false);我怀疑编码和bzcompression可能有问题，所以我用gzdeflate替换了bzcompress，并将curl代码改为
curl_setopt($ch,CURLOPT_HTTPHEADER,array('Content-Type:text/plain'));
curl_setopt($ch,CURLOPT_ENCODING,'');
curl_setopt($ch,CURLOPT_URL,$url);
curl_setopt($ch,CURLOPT_POST,1);
curl_setopt($ch,CURLOPT_POSTFIELDS,"{$cql}");然而，“解决方案”纯粹是在阅读PHP文档和这里的一些帖子的基础上拼凑出的一个替代方案的结果--对于我正在做的一个小的使命的任务部分来说，这并不是一个值得依赖的东西。
那么问题来了--这里发生了什么？为什么原始代码在处理较长的数据字符串时会失败，为什么后一个版本能工作？它会一直工作吗？还是缺少了什么？
我将非常感谢任何帮助和提示。
1条答案
按热度按时间klsxnrf11#
我可以回答我自己的问题。我上面概述的“解决方案”只不过是一条红鲱鱼。它不会让你有任何结果，所以不要费心去尝试它。
这里真实的的问题是最好的理解，注意到所讨论的服务器是Lighttpd。在研究了一些问题之后，我发现它有一个不幸的习惯，当它收到一个带有httpExpect：100-继续标题。
要么它看起来是以间歇的方式执行此操作，要么libcurl以间歇的方式附加此标头--可能是在POST数据长度超过某个阈值时。
无论如何，这是我的问题的根源。
行，然后重新加载服务器配置
这可以防止您自己的Lighty安装在遇到Expect 100-Continue时崩溃，但是如果您发出的libcurl请求到达Lighty（或其他）服务器，而该服务器在看到这一情况时沮丧地举起手来，这就没有什么作用了。