It’s been a while since I’ve worked with PEAR, but I believe VuFind sets up some kind of custom PEAR error handling function. It’s possible that this configuration causes the PEAR_Error constructor to call the error handler and short-circuit everything else, which would explain why error handling seems to be working in spite of the void function call. I’m speaking from dim memory here, so I might be completely mistaken, and if I’m right about this, it’s totally unintuitive (and I’m glad we’re rid of it!), but I think it would explain what you’re seeing.


- Demian


From: anna headley []
Sent: Tuesday, April 22, 2014 8:57 AM
To: Demian Katz
Subject: Re: [VuFind-Tech] elusive 'malformed response' error


Hey Demian,


Sorry I wasn't clear.

My side question is I guess not really about the line of code I copied but more about sendRequest [1]: how does it ever return anything but null? There is no return statement. I'm looking at php docs and they say that if there's no return statement the method returns null. Does it actually pass through the value its parent returns? If so the in-line docs, which say its return value is void, are kind of wrong but this is moot since that version is dead. Anyway this is a total side note; I probably should have posted it on stackoverflow.

My actual problem regards the stacktrace I posted! When I look at the code it seems like the error is handled. And yet it comes through to the page. Is there some way that pear could be generating an error that short-circuits the error handling in this stack?


[1] (line 80)



On Mon, Apr 21, 2014 at 5:44 PM, Demian Katz <> wrote:

$http won't be null in that situation -- in an error, sendRequest returns a PEAR_Error object. PEAR::isError checks the type of the return value to see if it is a PEAR_Error. That return statement should only be executed if $http is an instance of PEAR_Error. Does that make any sense?

- Demian

From: anna headley []
Sent: Monday, April 21, 2014 2:47 PM
Subject: [VuFind-Tech] elusive 'malformed response' error

Hi all,

Vufind 1.3! the past two tuesday nights we've had periods of displaying malformed response errors instead of record pages due to recent server problems at Syndetics. I went in to try to improve error handling but it looks like everything is being handled correctly. It seems like the error we're getting is quitting out before it gets a chance to reach the error handling. stacktrace below -- any insights?

Relatedly, how does the following code work given that sendRequest has no return statement? Won't $http always be null?

web/sys/Excerpts.php line 161:
if (PEAR::isError($http = $client->sendRequest(true))) {
              return $http;



Apr 15 22:30:39 vufind [error] [pear_error: message="Malformed response" code=16 mode=callback callback=handlePEARError prefix="" info=""]
/usr/share/pear/PEAR.php line 533 - class = PEAR_Error, function = PEAR_Error
/usr/share/pear/HTTP/Request.php line 1225 - class = PEAR, function = raiseError
/usr/share/pear/HTTP/Request.php line 753 - class = HTTP_Response, function = process
/usr/local/vufind_trico_1.3/web/sys/Proxy_Request.php line 110 - class = HTTP_Request, function = sendRequest
/usr/local/vufind_trico_1.3/web/sys/Excerpts.php line 161 - class = Proxy_Request, function = sendRequest
/usr/local/vufind_trico_1.3/web/sys/Excerpts.php line 246 - class = ExternalExcerpts, function = _syndetics
/usr/local/vufind_trico_1.3/web/sys/Excerpts.php line 78 - class = ExternalExcerpts, function = _syndeticsplus
/usr/local/vufind_trico_1.3/web/RecordDrivers/IndexRecord.php line 385 - class = ExternalExcerpts, function = __construct
/usr/local/vufind_trico_1.3/web/RecordDrivers/IndexRecord.php line 961 - class = IndexRecord, function = getExcerpts
/usr/local/vufind_trico_1.3/web/services/Record/Record.php line 167 - class = IndexRecord, function = hasExcerpt
/usr/local/vufind_trico_1.3/web/services/Record/Home.php line 57 - class = Record, function = __construct
/usr/local/vufind_trico_1.3/web/index.php line 212 - class = Home, function = launch