[Andrew Swingler]

First, I want to say Thank You! to Craig and his team for making this API available. Very much appreciated.


To be honest, I don't think that this is a problem with the API, but I was wondering if anyone else has seen this problem or could offer a suggestion for a fix.

I developed a working app to pull KB entries out of Kayako using the SOAP service and put them on our website. Locally everything works just fine, but when we moved the app to our QA server we got a strange response from the web-service call. Tests were done using the same browser on the same machine, with the same Kayako data-source. Code was identical on both sites. I tried IE, Chrome and FireFox and all results were the same.

On the LOCAL (working) site the response was:

CODE

<?xml version="1.0" encoding="utf-8" ?><xjx><cmd n="as" t="artRow_46_91" p="style.display"><![CDATA[]]></cmd><cmd n="as" t="artBody_46_91" p="innerHTML"><![CDATA[Our Contact page is located <a title="Contact Us" href="http://172.16.70.18/pages/contact_us.html">here</a>.]]></cmd></xjx>

On the QA (not-working) site the response was:

CODE

<?xml version="1.0" encoding="utf-8" ?><xjx><cmd n="as" t="artRow_46_91" p="style.display"><![CDATA[]]></cmd><cmd n="as" t="artBody_46_91" p="innerHTML"><![CDATA[Our Contact page is located a title=Contact Us href=http://172.16.70.18/pages/contact_us.htmlhere/a.]]></cmd></xjx>

Notice the difference? The response from the QA site stripped out all the html special chars in the CDATA section, whereas the response from the LOCAL site did not (which is what we want).

I compared PHP.INI and HTTPD.INI and didn't see anything that would cause this discrepancy.

Can anyone suggest a reason for this? This thing is driving me nuts!

Andrew.

[Andrew Swingler]

UPDATE: It looks as though I've found the culprit.

According to this post on the NuSOAP forum: http://sourceforge.net/forum/forum.php?thr...forum_id=193579 the problem exists on PHP version 5.2.6 but not on 5.2.5.

And that matches what I'm seeing - my LOCAL (working) site is running on 5.2.5 while my QA (broken) site is running on 5.2.6.

Hope this helps someone.

Andrew.

[Andrew Gillard]

It sounds like you're using PHP's built-in SOAP library. If that's the case, have you tried using NuSOAP instead? It isn't as "pretty", and since it's written in PHP instead of C it's no doubt somewhat slower, but I found it to work better during our testing.

[Andrew Swingler]

It sounds like you're using PHP's built-in SOAP library. If that's the case, have you tried using NuSOAP instead?

Thanks for getting back to me Andrew. In fact we are using NuSOAP. This is a known issue with PHP 5.2.6 and NuSOAP (see the NuSOAP forum entry mentioned below).

Unfortunately we haven't found a workaround for the problem yet, but now that we know that it's either PHP or NuSOAP that's causing the problem, we can focus our attention there.

Andrew.

[Andrew Gillard]

Ah yes, I missed that, sorry. In that case, have you tried PHP's built-in SOAP client library, if it's a possibility? http://www.php.net/manual/en/book.soap.php

It's nice to know that it's not anything we've done wrong, but at the same time, if there's anything that we can do to work around the problem, or warn users about, I'd like to know about it (Besides, "don't use PHP 5.2.6", which isn't always an option, especially in shared hosting environments...)

[Andrew Swingler]

It's nice to know that it's not anything we've done wrong, but at the same time, if there's anything that we can do to work around the problem, or warn users about, I'd like to know about it (Besides, "don't use PHP 5.2.6", which isn't always an option, especially in shared hosting environments...)

If I figure this thing out I'll definitely post it here.

I just loaded 5.2.6 locally (on the machine where it's been working) as a cgi app on a vhost, but I left the module version as 5.2.5. In theory I can switch between the two versions just by selecting a different port, and indeed that seems to work just fine. The interesting thing is that in the local 5.2.6 environment things DO seem to work properly (ie same as 5.2.5). If this is indeed the case (rather than perhaps Apache using the module version for the web-service call) it changes the game somewhat.

Something else that's different between the working and non-working environments is that local (working) is a windows install, and QAS (non-working) is a CentOS install.

Anyway, I'll post what I find.
Andrew.

[Andrew Swingler]

UPDATE: it's not 5.2.6. I blew away 5.2.5 locally and installed 5.2.6. Locally it still works fine. I'll update the NuSOAP thread with this info.

[Andrew Swingler]

Okay, I have an answer to this problem, and a (not pretty) workaround.

This problem is being caused by problem with libxml2 (see this bug: http://bugs.php.net/bug.php?id=45996 ).

Apparently, if you're running libxml2 with a version later than 2.6.32 you'll see this behaviour.

This makes sense, as my local install is running 2.6.32 which works fine, while my remote install is running 2.7.2 and is broken.

There are two possible workarounds:
- Build PHP with a version of libxml2 <= 2.6.32
- Build PHP using libexpat

So, if you're running a 'bad' version of libxml2 the only known workarounds currently involve rebuilding PHP.

Enjoy!

Andrew.

[Andrew Gillard]

Great, thanks for that I've created a sticky thread about it.