Assuming that $r is a HTTP::Request, I would pass the request data in using the ->content method of HTTP::Request instead of relying on the magic of LWP::UserAgent picking up the correct file or knowing what to do with $data.

Also, have you looked at what SOAP::Lite XML would construct as a request? If you can get SOAP::Lite to construct the request for you, maybe you can compare that with the request your program constructs and find the difference?

Thanks

The content function of HTTP::Request was the key. I also used the header function to set the content type as text/xml. That got it working, in the sense I now have proof that my code is sending content, and that the server is processing it.

I did look at SOAP::Lite, but it seemed like overkill as all these guys use SOAP for is to structure the XML messages it expects to receive and those it sends in response.

Thanks

Ted

Links to soap tips including getting tidy debugging info in Re: Why can't SOAP::Lite deserialize its own output? (it does)

Thanks. That's a little light reading. ;-)

Ted

To answer your second question, try dumping the POST data with

$q->param('POSTDATA');
[download]

Disclaimer: I've written a number of SOAP clients and servers, but none in Perl for many years.

Thanks.

Alas, I do not have access to the server logs. I did not create this server, and do not have access to it's code. What I have learned is that the guys responsible have coded it in Java, as a servlet. It does not handle errors well (key java exception data is passed to the client rather than processed server side; with only suitably sanitized but useful error messages being sent to the client). I regard passing a full stack trace to a client as poor practice; but that's just me I suppose.

I will have to look into the SOAPAction HTTP header. At present, I only set the content type header as text/xml

I will definitely take a look at use of $q->param('POSTDATS'); to get data that was not collected from a form.

Thanks again

Ted