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 :^) .
Announcement
Collapse
No announcement yet.
debugging SOAP MvCALL
Collapse
X
-
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?
Leave a comment:
-
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".
Leave a comment:
-
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 --
Leave a comment:
-
Not sure I am following. Are you doing any EVALs of call values?
Code:<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) }">
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
Leave a comment:
-
debugging SOAP MvCALL
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 --Last edited by Kent Multer; 08-15-18, 12:38 AM.Tags: None
Leave a comment: