debugging SOAP MvCALL

[Kent Multer]

Hi folks,

I'm doing a custom project that uses MvCALL to make requests to a server using the SOAP protocol. I always find SOAP hookups a little tricky; and in this case, the problems are exacerbated by a support staff that doesn't seem very supportive :^.

After working thru a couple of other problems, I'm getting a reply that states, "413 Request Entity Too Large. The requested resource /index.php does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit." I'm using MvCALL with METHOD="XML," so it certainly should be sending POSTs. Is there anything else I could have done wrong, that would cause MvCALL to send a garbled request? In case it matters, I should mention that the URL includes a "?name=value" parameter.

I'm thinking that what I need is some sort of debugging tool or script that I can use by having my module send requests to this script, instead of to the server. The script's job would be simply to write into a log file, or perhaps send back in the reply, a complete description of the request that it received: the HTTP method, all the headers, and all the data. That way, I can see exactly what my module is sending.

I don't think I can write this in Miva Script, because Miva Script doesn't provide a way to read the body of an incoming POST request that consists of pure data instead of name-value pairs. I could write this in PHP, but it would probably take me a couple of hours of fiddling; I don't use PHP that often. I'm hoping someone here can point me to an off-the-shelf tool, or maybe you already have a script that does this?

Thanks --

[ILoveHostasaurus]

How much data are you sending?

[Kent Multer]

about 600 bytes. It's a SOAP XML request with just a few tags.

[ids]

Not sure I am following. Are you doing any EVALs of call values?

                    <MvEVAL EXPR = "{ s.callreturnheader2 $ '<br/>' }">
                    <MvEVAL EXPR = "{ s.callreturnheader3 $ '<br/>' }">
                    <MvEVAL EXPR = "{ s.callreturnheader4 $ '<br/>' }">
                    <MvEVAL EXPR = "{ s.callreturnheader5 $ '<br/>' }">
                    <MvEVAL EXPR = "{ s.callreturnheader6 $ '<br/>' }">
                    <MvEVAL EXPR = "{ s.callreturnheader7 $ '<br/>' }">
                    <MvEVAL EXPR = "{ s.callreturnheader8 $ '<br/>' }">
                    <MvEVAL EXPR = "{ s.callreturnheader9 $ '<br/>' }">            
                    <MvEVAL EXPR = "{ s.callvalue $ '<br />----------------<br />'}">            
                    <MvASSIGN NAME = "l.myreturn" VALUE = "{ miva_json_decode(s.callvalue, l.returnJSON) }">

That helped me figure something out in a recent module I've worked on.

Also, I think I had an issue a while back trying to send XML as name-value pair. Ended up canceling that project because regardless of what I tried, at the time, RAW, POST, XML... that endpoint wouldn't parse the variations of requests I was submitting.

Scott

[Kent Multer]

I know about the system variables. But as you found out, SOAP servers expect the request data to be just a chunk of XML with no name=value format. That's why the XML and RAW methods were added to MvCALL. But, unless something new has been added and I missed the release notice, Miva Script still has no way to *read* data that is sent to it in a POST request unless the data is in the name=value form.

So I can't write a quick Miva Script to debug what my module is sending, because there's no way for a Miva Script program to read the complete body of a POST as one unnamed chunk of data. Looks like I'll need to write some PHP, unless someone here can help me, or I can find a free tool somewhere on the Net.

P.S. In-house devs, please add that (receiving unnamed data) to the wish list. Thanks --

[burch]

This has been supported since 5.18. From the release notes:

- POST content types other than application/x-www-form-urlencoded and
multipart/form-data are now supported. This allows XML and other non-form
based data to be POSTed directly to a MivaScript application. To prevent
DOS attacks, the maximum length of unknown content types may be controlled
by the MvCONFIG_MAX_UNKNOWN_CONTENT_LENGTH (environment based configuration)
or "maxunknowncontentlength" (3.x configuration) directive, which limits the
maximum number of bytes of content that may be submitted. The default value
is 1MB. A value of 0 allows an unlimited amount of content (still subject
to the POST timeout) and a value of -1 disables acceptance of unknown
content altogether.

The POST content is not parsed in any way and is made available to the script
in system variable "s.content_data".

[Kent Multer]

So I did miss a release notice :^. Thanks, Burch, that will be a big help.

If I run into a case where I need to receive more than 1MB of data, how do I change that limit?

[Kent Multer]

Woo-hoo, found the problem! What a relief; that one's been kicking my tail for a week.

Note to other developers writing MvCALLs: DON'T create your own Content-Length header, let Miva do it. Once I removed that, everything started working normally. This must have been changed in recent years, because I copied code from some older modules to write this new one, and those modules did create their own Content-Length.

The redundant header really messes things up badly. I wrote a test script to display s.content_data and other system variables, but the redundant header was causing the server to reject the entire request with a 400 error; it didn't even get as far as running my script. Once I saw that, I started stripping pieces out of the MvCALL until it started working.

Thanks, everybody, for your help and/or moral support :^) .