Http Client with Curl / default adapter and transfer-encoding chunked: Error parsing body - doesn't seem to be a chunked message #65
Description
This issue has been moved from the zendframework repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.html
Original Issue: https://api.github.com/repos/zendframework/zendframework/issues/7683
User: @lucian303
Created On: 2016-03-09T17:15:25Z
Updated At: 2016-05-03T14:31:29Z
Body
Once I set the adapter to Socket, it works, but with Curl or the default adapter (which I assume is Curl), I get this message on chunked encodings. From looking at other tickets and my own experience with prior Zend versions, it looks like the Socket adapter used to be unable to handle the chunked transfer encoding while the Curl one was able to and now that has flipped in ZF 2.5.3. In 2.2.10 for example, I'm 99.9% sure it's the other way.
Comment
User: @marcelto
Created On: 2016-03-09T19:13:57Z
Updated At: 2016-03-09T19:13:57Z
Body
This may not be relevant but in the past I've found that curl sometimes has trouble with chunked responses. To work around the issue I had to set the HTTP version to 1.0.
curl_setopt($ch, \CURLOPT_HTTP_VERSION, \CURL_HTTP_VERSION_1_0);
Comment
User: @lucian303
Created On: 2016-03-09T19:52:27Z
Updated At: 2016-03-09T19:52:27Z
Body
So I did more investigation and found the culprit in Zend\Http\Client\Adapter\Curl.php:437:
$responseHeaders = preg_replace("/Transfer-Encoding:\s*chunked\\r\\n/", "", $responseHeaders);
Should be:
$responseHeaders = preg_replace("/Transfer-Encoding:\s*chunked\\r\\n/i", "", $responseHeaders);
Notice the 'i' in the regex. It should be a case insensitive match as HTTP headers are case insensitive: https://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
Comment
User: @lucian303
Created On: 2016-03-09T20:12:03Z
Updated At: 2016-03-09T20:12:03Z
Body
See pull request: #53
Comment
User: @sgehrig
Created On: 2016-05-03T14:30:18Z
Updated At: 2016-05-03T14:31:29Z
Body
Isn't that a duplicate of #19
Any idea when this would be fixed?