Edit report at https://bugs.php.net/bug.php?id=55438&edit=1
ID: 55438
Comment by: phpnet at lostreality dot org
Reported by: xuefer at gmail dot com
Summary: race condition: curlwapper is not sending http
header randomly
Status: Assigned
Type: Bug
Package: cURL related
Operating System: gentoo
PHP Version: 5.3.6
Assigned To: pierrick
Block user comment: N
Private report: N
New Comment:
Ok, thanks for the info. I was mostly wondering if it would make 5.3.x at all.
Well now it seems I just have to wait for 5.3.21 to be released, and CPanel to
upgrade, and so on :)
Previous Comments:
------------------------------------------------------------------------
[2012-12-19 16:57:15] pierr...@php.net
Unfortunately, it's to late for 5.3.20 and 5.4.10, sorry.
It will only be available in 5.3.21 and 5.4.11
------------------------------------------------------------------------
[2012-12-19 15:17:12] phpnet at lostreality dot org
Great. Any chance this can make it to 5.3.20 also?
------------------------------------------------------------------------
[2012-12-19 07:51:36] pierr...@php.net
Ok, I finally reproduced the problem.
I was trying the code snippet on my local network and everything was fine, once
I modified the code to fetch an URL on a slower network I had the problem.
Since curl multi is used, it sometime happen that the resource is freed before
the curl multi really execute the query. The patch looks good, I'll have a
second look tomorrow and will commit it.
Thanks for your help on this one :)
------------------------------------------------------------------------
[2012-12-19 06:01:04] phpnet at lostreality dot org
I have curl-7.15.5-15.el5 according to rpm -q, but I can only locate
/usr/lib/libcurl.so.3.0.0 and /usr/lib64/libcurl.so.3.0.0 on my machine I'm
testing on (CentOS 5.8). The binary says: /usr/bin/curl -V
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3
libidn/0.6.5
Normally, I use the stock RPMs for PHP, but a recent project I was working on
failed to run properly on another machine, where the owners also use CentOS
5.8, but use CPanel/WHM instead of the CentOS RPMs for PHP. CPanel uses the
--with-curlwrappers option, where as the stock CentOS and RHEL RPMs have never
used that option on any of their builds. It took a lot of digging before I
realized that it was the --with-curlwrappers option that caused the scripts to
fail on that machine while working perfectly on mine.
To verify if the headers were actually sent, I used: tcpdump -i eth1 -Als0 host
www.example.com
I had two PuTTY windows open, one with tcpdump, the other running the test
script I mentioned before with: ./php-5.4.9/sapi/cli/php ./test.php
It was pretty clear to me that the headers were never sent before the patch,
and always sent after the patch.
------------------------------------------------------------------------
[2012-12-19 05:50:16] pierr...@php.net
I tried to reproduce this bug but wasn't able to do it.
Could you give me more details on the libcurl version used by your PHP instance
?
And also, how do you make sure that the headers are not properly sent ?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=55438
--
Edit this bug report at https://bugs.php.net/bug.php?id=55438&edit=1
