Edit report at https://bugs.php.net/bug.php?id=67584&edit=1
ID: 67584
User updated by: marcus at synchromedia dot co dot uk
Reported by: marcus at synchromedia dot co dot uk
Summary: Misleading error in pecl_http 2.0.x
Status: Assigned
Type: Bug
Package: HTTP related
Operating System: OS X
PHP Version: 5.4.30
Assigned To: mike
Block user comment: N
Private report: N
New Comment:
I've managed to grab your latest code from the git repo, but I don't know how to tell it
where to find the raphf header files so it's failing when I do a 'pecl build'. I
installed raphf and propro from source via homebrew, so their header files are in
/usr/local/Cellar/php54-raphf/1.0.4/include and /usr/local/Cellar/php54-propro/1.0.0/include.
Previous Comments:
------------------------------------------------------------------------
[2014-07-08 11:02:11] marcus at synchromedia dot co dot uk
I'll have a go with a fresh build.
I just tried a few variations on the breakpoint. The segfault happens when I set a breakpoint on the
'$url = ...' line. I run the script in debug mode - it echoes the first class name, then
quits with an error 139, which is a segfault. I'm running xdebug 2.2.5 in PHP 5.4.30 built from
homebrew on OS X 10.9.4.
Without the breakpoint, it does not segfault and completes successfully.
------------------------------------------------------------------------
[2014-07-08 10:23:16] mike@php.net
I forgot to answer the question about the originating request:
The response has its request as parent message:
$request = $response->getParentMessage();
------------------------------------------------------------------------
[2014-07-08 10:21:01] mike@php.net
Disregard the exception behavior I gave before, it seems I tripped over old memory.
$response->getTransferInfo("error") should contain the same information like the
exception message.
I committed a fix for the uninitialized response object to R_2_0 and master. Could you try one of
those?
Do you mean that "get_class($response);" segfaults with XDebug?
I'll have a look! What's your XDebug version=?
------------------------------------------------------------------------
[2014-07-07 15:48:20] marcus at synchromedia dot co dot uk
Thanks for getting back to me.
If I issue my requests with:
while (@$client->once()) {
$client->wait();
}
Where would failure information be stored when iterating over the output of getResponse afterwards?
Dealing with them inside that loop seems like it might interfere with the parallel nature of the
requests? If not, how can I get a handle on which Request object caused the error, assuming they
could complete or fail in random order?
When you say "I'll fix that", do you mean that getResponse will return a proper
Response instance with error info instead of complaining it's a Message?
I'm using this in two places - a link checker and an image grabber - where I want all the
requests to happen (even if some fail), in parallel, and assess the responses afterwards.
I'm also getting consistent segfaults in the test script on the first line inside the
getResponse loop if I step through it with xdebug (in PHPStorm). I don't know if that's
your department.
------------------------------------------------------------------------
[2014-07-07 14:52:50] mike@php.net
I'm sorry you've had such a hard time using this library.
As already noted at your comment in the docs, all of those methods are actually http\Message
methods. http\Client\Response is just a thin layer adding exactly those few methods as documented.
If the response raises that error (thanks for spotting thy typo) it basically means a response was
never received and the message is completely blank. Basically an uininitialized http\Message.
I'll fix that.
Now to your use case. If an exception occurs everything else currently executing is stopped of
course. If the first thing that happens is a DNS exception nothing else happened. You have to use
the more fine grained API if you want information of the single requests you were issuing; see http://devel-m6w6.rhcloud.com/mdref/http/Client/once
which throws warnings instead of exceptions.
------------------------------------------------------------------------
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=67584
--
Edit this bug report at https://bugs.php.net/bug.php?id=67584&edit=1