Announcement

Collapse
No announcement yet.

debugging SOAP MvCALL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Kent Multer
    replied
    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 :^) .

    Leave a comment:


  • Kent Multer
    replied
    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:


  • burch
    replied
    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:


  • Kent Multer
    replied
    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:


  • ids
    replied
    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) }">
    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

    Leave a comment:


  • Kent Multer
    replied
    about 600 bytes. It's a SOAP XML request with just a few tags.

    Leave a comment:


  • ILoveHostasaurus
    replied
    How much data are you sending?

    Leave a comment:


  • Kent Multer
    started a topic debugging SOAP MvCALL

    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.
Working...
X