I've dug through the code a bit more, and I can now see where the
Near line 559 of xmlrpc.inc, there is the following:
// gotta get rid of headers here
if ((!$hdrfnd) && ereg("^(.*)\r\n\r\n",$data,$_xh[$parser]['ha']))
$data=ereg_replace("^.*\r\n\r\n", "", $data);
Which is failing to remove the headers in the case I describe below. I
can print $data before and after this section of the code, and all of
the HTTP headers are still in place. This only appears to fail when
$data is larger than about 20kbytes. I'm rewriting this section in a
way that should be able to handle larger data segments.
I'll post a patch as soon as it's ready...
On Fri, Aug 24, 2001 at 01:16:10AM -0700, Jason L. Buberel wrote:
> I'm using 1.0b9 with PHP 4.0.4 on RedHat 7.1 Apache 1.3.19.
> I have successfully gotten a few simple rpc calls working (send in a few
> strings, get a string back, etc.). I am now working on implementing a
> function that will return a struct of 7 arrays.
> In the rpc-server, I am using the following to create the reply:
> // use the handy encode method to encode each of these arrays...
> $guid_val = xmlrpc_encode($guid);
> $location_val = xmlrpc_encode($location_id);
> $city_val = xmlrpc_encode($city);
> $state_val = xmlrpc_encode($state);
> $hostname_val = xmlrpc_encode($hostname);
> $uri_val = xmlrpc_encode($uri);
> $version_val = xmlrpc_encode($version);
> // then create a struct from the seven arrays...
> $struct = array ( 'guid' => $guid_val,
> 'location_id' => $location_val,
> 'city' => $city_val,
> 'state' => $state_val,
> 'hostname' => $hostname_val,
> 'uri' => $uri_val,
> 'version' => $version_val);
> // return the struct...
> return new xmlrpcresp ( new xmlrpcval ($struct, 'struct'));
> Each time the method is called, I get a fault code = '2' with a fault string
> of "Invalid return payload".
> In addition, the string:
> "XML error at line 1, check URL"
> ...is printed on standard error. This string is located on line 567 of
> xmlrpc.inc. This error message is reached only when the call to 'xml_parse'
> returns with FALSE, and when the parser says it is still on line number 1. So
> far, it seems like a problem with the parser (either expat itself or the PHP
> wrapper code around it).
> Here is the funny part: I then turn on the debug flag and rerun the test
> client to get a look at the return payload. To the naked eye, the XML reply
> looks perfect. There are no strange error messages, no extra headers, etc. It
> starts with the usual:
> <?xml version="1.0"?>
> and ends with the usual...
> I even checked the size of the XML payload against the HTTP content size
> header (Content-length: 25328), and the values are correct
> I have googled on that error message, and it doesn't turn up any exact
> Does anyone have any good ideas on what is causing the XML parse failure to
> Thanks for any help,
> For information about how to subscribe and unsubscribe from this list
> visit http://xmlrpc.usefulinc.com/list.html
For information about how to subscribe and unsubscribe from this list