Using 'Charles Proxy' To Debug PHP SOAP
The Web Dev Zone is brought to you in partnership with Mendix. Discover how IT departments looking for ways to keep up with demand for business apps has caused a new breed of developers to surface - the Rapid Application Developer.
I used this trick to solve a particularly sticky problem last week, so I thought I'd share. I had a 3rd party SOAP service (except it was actually a .NET WCF service, which is almost SOAP but not quite) which didn't behave in accordance with the way its documentation said it would. PHP's
SoapClient has the ability to enable tracing and give information about the request/response headers/body, which is useful, but I needed to store the outputs and also rewrite a particular request header during the course of debugging this. Enter: Charles Proxy.
I wrote about Charles at length on TechPortal recently, so if you're new to Charles that would be a good place to learn more. I set up Charles to proxy requests on port 8888, and I was running the PHP scripts on the same machine. To set the proxy, I simply added some entries to the
$options array that gets passed to the
$options = array( "cache_wsdl" => WSDL_CACHE_NONE, "soap_version" => SOAP_1_1, "trace" => 1, "proxy_host" => "localhost", "proxy_port" => 8888, ); $client = new SoapClient($wsdl, $options);
The specific bits that are relevant to proxying through Charles here are the
settings, this sends these SOAP requests through port 8888 on my local
machine, which is where Charles is listening for proxy activity. This
means that I can easily keep one eye on the detail of the request
without having large headers or SOAP responses all over my output or in
the logs. As I mentioned earlier, there was also a moment where we
thought that PHP was sending some incorrect headers (it wasn't) and I
was able to use Charles to rewrite just those headers, which helped us
to see that this wasn't the problem. You can also set a
stream_context option to set any specific HTTP-related settings you need to, but some headers such as
Content-Type will be ignored as the SOAP extension has clear ideas on which to send.
I hope that helps someone working with a remote SOAP service, they
aren't always easy to debug but this is one of many tools in my box so I
thought I'd share.