Page 1 of 2
XML-RPC sends back strange characters in addition to XML
Posted: Mon Feb 19, 2007 3:01 pm
by kortenkamp
Hi,
I'm trying to use the metaWeblog.newPost RPC call, which works, but the response that comes back includes invalid characters and also error messages that make my XML parser fail on the other end. Any guess what's going wrong there?
Here is the conversation. I send:
Code: Select all
POST /serendipity_xmlrpc.php HTTP/1.1
Content-Type: text/xml
Content-Length: 662
User-Agent: Java/1.5.0_07
Host: blog.myhost.tld
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive
<?xml version="1.0" encoding="ISO-8859-1"?><methodCall><methodName>metaWeblog.newPost</methodName>
<params>
<param><value><string>1</string></value></param>
<param><value><string>myusername</string></value></param>
<param><value><string>mypassword</string></value></param>
<param><value><struct>
<member><name>dateCreated</name><value><dateTime.iso8601>20070219T14:49:00</dateTime.iso8601></value></member><member><name>description</name><value><string>Super! es klappt</string></value></member>
<member><name>title</name><value><string>Test Post</string></value></member></struct></value></param>
<param><value><boolean>1</boolean></value></param></params></methodCall>
and I receive:
Code: Select all
HTTP/1.1 200 OK
Date: Mon, 19 Feb 2007 13:43:03 GMT
Server: Apache/2.0.54 (Debian GNU/Linux) PHP/4.3.10-18
X-Powered-By: PHP/4.3.10-18
Set-Cookie: PHPSESSID=a5008e33bbbd3bf69ae406ca4ed25220; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
X-Serendipity-InterfaceLangSource: Content-Negotiation
X-Serendipity-InterfaceLang: de
Set-Cookie: serendipity[old_session]=a5008e33bbbd3bf69ae406ca4ed25220; expires=Wed, 21 Mar 2007 13:43:04 GMT; path=/; domain=blog.kortenkamps.net
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/xml
2dc
<br />
<b>Warning</b>: Cannot modify header information - headers
already sent in <b>/var/www/serendipity/plugins/serendipity_event_xmlrpc/PEAR/XML/RPC/Server.php</b> on
line <b>399</b><br />
<br />
<b>Warning</b>: Cannot modify header information - headers
already sent in <b>/var/www/serendipity/plugins/serendipity_event_xmlrpc/PEAR/XML/RPC/Server.php</b> on line <b>399</b><br />
<?xml version="1.0" encoding="ISO-8859-1"?>
<methodResponse>
<params>
<param>
<value><string>45</string></value>
</param>
</params>
</methodResponse><br />
<b>Warning</b>: Cannot modify header information - headers
already sent in <b>/var/www/serendipity/plugins/serendipity_event_xmlrpc/serendipity_event_xmlrpc.php</b> on
line <b>60</b><br />
0
Observe the "2dc" string in the response -- that one shouldn't be there, and I have no idea where it comes from...
any clues?
Thanks,
Ulli[/code]
Possible Cause?
Posted: Tue Feb 20, 2007 11:01 am
by kortenkamp
Hi,
I found that ./plugins/serendipity_plugin_remoterss/UTF-8/lang_pl.inc.php, ./plugins/serendipity_event_spamblock/UTF-8/lang_pl.inc.php, ./plugins/serendipity_event_statistics/UTF-8/lang_pl.inc.php , ./plugins/serendipity_event_bbcode/UTF-8/lang_pl.inc.php and a lot of other files starts with three characters (that probably mark this file as UTF-8) -- might that be the problem?
Ulli
Re: Possible Cause?
Posted: Tue Feb 20, 2007 11:03 am
by garvinhicking
Hi!
You are right on the assumption that the '2dc' must come from some file or any PHP code you are including.
The 3 bytes in the language files are a UTF-8 BOM message. You are right that they should not be there. But they are only included if you use Polish language, which I suspect you're not doing?
Best regards,
Garvin
No, no polish...
Posted: Tue Feb 20, 2007 11:26 am
by kortenkamp
Garvin,
you are right, I'm not using Polish. And it also did not help to remove them...
I still experience the same problem, however, now the three characters are 22d...
Do you have any guess where they come from? Or is there a way I can turn on debugging for tracing this? I tried to understand the code, and although it's quite clean, it's hard to follow all things that happen when I do the RPC call...
Ulli
Re: No, no polish...
Posted: Tue Feb 20, 2007 11:30 am
by garvinhicking
Hi!
I still experience the same problem, however, now the three characters are 22d...
Hm. That sounds as if not a string "22d" is emitted somewhere, but maybe some individual files.
You could go into the file /var/www/serendipity/plugins/serendipity_event_xmlrpc/PEAR/XML/RPC/Server.php at line 399 and add some debugging output. Let yourself see the output of
http://de2.php.net/get_included_files and check if any of those files have extra output somewhere. Especially check if there are any files included outside of the s9y directory.
Sadly, tracing those outputs is VERY hard to do, if not the hardest thing in PHP Debugging.
It must be somehow related to your custom files or any modifications, because in a default s9y installation those characters do not show up...
HTH,
Garvin
Posted: Tue Feb 20, 2007 11:36 am
by kortenkamp
It must be somehow related to your custom files or any modifications, because in a default s9y installation those characters do not show up...
But I did not modify anything... I'll see whether I find the problem.. thank you for the starting points...
Ulli[/quote]
Posted: Tue Feb 20, 2007 11:37 am
by garvinhicking
Hi!
Ah, okay, so all of your s9y files are unmodified?
The the only thing I could know of would be a strange PEAR install. Try to edit your serendipity_config.inc.php file and set $serendipity['use_PEAR'] = false; - this will bypass any PEAR installed on your server...
HTH,
Garvin
Posted: Tue Feb 20, 2007 12:08 pm
by kortenkamp
garvinhicking wrote:Hi!
Ah, okay, so all of your s9y files are unmodified?
The the only thing I could know of would be a strange PEAR install. Try to edit your serendipity_config.inc.php file and set $serendipity['use_PEAR'] = false; - this will bypass any PEAR installed on your server...
HTH,
Garvin
No, unfortunately not. I do have several PEAR.php files on the system, but they are used by other domains, and I don't think they interfere. Also, setting this to false did not change anything.
Ulli
Re: No, no polish...
Posted: Tue Feb 20, 2007 12:12 pm
by kortenkamp
garvinhicking wrote:
Sadly, tracing those outputs is VERY hard to do, if not the hardest thing in PHP Debugging.
In particular if you don't know PHP, like me
However - is there a way to do somthing like a stack trace when the header is written? Actually, the 22d output triggers that the header is shipped out, so when this happens, there should be a possibility to find out what caused it, shouldn't there?
Ulli
Posted: Tue Feb 20, 2007 12:12 pm
by garvinhicking
Hi!
I just found out that the '2dc' is coming from the HTTP header, it indicates the 'chunked' transfer split code - at least I think so.
So it seems there's just a blank newline being emitted somewhere. Could you temporarily change your blog and personal preferences (both!) to the english language? Then we could exclude a bug in the german language files.
Also, could you try to replace the xmlrpc plugin with contents frmo the ZIP from
http://spartacus.s9y.org/? It might be that if you fetched it via Spartacus there are some misaligned bytes
, or maybe if you editted the file with a windows editor, a windows linebreak might have gotten there.
HTH,
Garvin
Posted: Tue Feb 20, 2007 12:35 pm
by kortenkamp
garvinhicking wrote:Hi!
So it seems there's just a blank newline being emitted somewhere. Could you temporarily change your blog and personal preferences (both!) to the english language? Then we could exclude a bug in the german language files.
Also, could you try to replace the xmlrpc plugin with contents frmo the ZIP from
http://spartacus.s9y.org/? It might be that if you fetched it via Spartacus there are some misaligned bytes
, or maybe if you editted the file with a windows editor, a windows linebreak might have gotten there.
did that - no change. And no Windows around, this is on a Debian machine...
By the way: When I do not have the rights to publish the article, then only a draft is stored in the database (which is correct, of course). But then everything works fine -- no additional line. Maybe that helps in finding out where it comes from?
Ulli
Posted: Tue Feb 20, 2007 12:54 pm
by garvinhicking
Hi!
By the way: When I do not have the rights to publish the article, then only a draft is stored in the database (which is correct, of course). But then everything works fine -- no additional line. Maybe that helps in finding out where it comes from?
Ah, that's a good hint. This can mean that any event plugin(s) involved when publishing an entry could be involved.
Which event plugins are you running? Your test entry does not contain any HTML links, right?
Regards,
Garvin
Posted: Tue Feb 20, 2007 1:00 pm
by kortenkamp
garvinhicking wrote:
Which event plugins are you running? Your test entry does not contain any HTML links, right?
Great! That brought us on track: I removed the "Announce Entries" plugin, and that solved the problem!
So, now it's only a matter of finding out which files of that plugin are bad
Thanks a lot!
Ulli
Posted: Tue Feb 20, 2007 1:17 pm
by garvinhicking
Hi!
The 'announce entries' plugin might have trouble accessing one of the sites that are configured; try to disable all of them and then enable the services one by one?
Regards,
Garvin
announce plugin
Posted: Tue Feb 20, 2007 1:26 pm
by kortenkamp
Strange -- the plugin disappeared... and I cannot reinstall it?!? How can that be?
Ulli