Announcement

Collapse
No announcement yet.

HTTP Sender "application/x-www-form-urlencoded"

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

  • HTTP Sender "application/x-www-form-urlencoded"

    version: Mirth Connect Server 3.4.2.8129

    The issue I am having is I need to send a content type of "application/x-www-form-urlencoded" with query parameters escaped with "=" and "+" in the query string. I would appear "application/x-www-form-urlencoded" for content type is encoding "=" as %3 and "+" as %2. Also the http service does NOT want to receive a query parameter name in the query. They want something like this:

    "UserEmail=test%40test.com&PatientId=1234&Timestam p=Thu%2C+07+Jan+2016+15%3A01%3A34+GMT&Token=aF7rlE aL99GVbuX8LJ35KKe7Qjesnck3S7CP0kqRvE27Xs7dDEj8sOXW 9UZp5Kb%2FyGZX2KMuT7yZzafadExLgES%2B%2FpHb3Agou%2F yTnfodkl5fMU%2FpU6ok%3D%3D"


    If I create an HTTP Sender for a post, set the content type as noted, and then create a query parameter with my query string named "data", Mirth is sending:

    "data=UserEmail%3dtest%2540test.com%26PatientId%12 34%26Timestamp%3dTue%252C%2b07%2bMar%2b2017%2b09%2 53A453D"


    They choke on the "data=" part so I put the query string in the "content" field instead, and changed the content-type to "text/plain". The query parameter name is gone, but they don't seem to like that as they are expecting "application/x-www-form-urlencoded".

    What I have attempted is to split my entire query string by " " (space) and then recombine it with "=" and "+", and for each array element I am using var newquery += encodeURIComponent(arrayelement[i]) to escape the text individually. If I do that I can see the string it produces is exactly what the vendor is expecting, HOWEVER it appears that "application/x-www-form-urlencoded" is then re-encoding the string to kill the "=" and "+".

    At this point I seem to be stuck between I have to put "application/x-www-form-urlencoded" in the content type, but I can't bypass Mirth's re-encoding of the query string. I have also tried to trick the content encoding piece by setting it to a variable in the code below "encoding". Doesn't seem to trick it though. To note I have all this code already working in C#.

    I am not a web developer but I do write Mirth interfaces so the restful http service needed writing so its on me. I had 2 other senders already working going to the same service, but those do not require application/x-www-form-urlencoded" and are working fine.

    BTW, I've tried Fiddler to view my outbound httprequests but I can't get it to show anything. I've read their config pages, and read what posts on this forum address attempting to config it for Mirth to no avail. I've also tried logger.info(msg) in the transformer step and it only spits out the inbound "source" message, not what Mirth is actually sending out to the vendor.

    I'm sure I'm missing something basic here. Can anyone point me in the right direction? Can I provide any further info? (sorry for the long post)

    var lvItems = {
    "key1": "test value 1",
    "key2": "test value 2"
    };


    lvReturn = "";
    var lvitem = "";
    var newquery= "";

    for(var key in lvItems)
    {

    var Split = lvItems[key].split(" ");
    var arrayLength = Split.length;
    for (var i = 0; i < arrayLength; i++) {
    if (newquery.length > 0)
    {newquery= newquery + "+" + encodeURIComponent(Split[i]);}
    else
    {newquery = encodeURIComponent(Split[i]);}
    }
    lvitem = newquery;
    }

    if (lvReturn.length > 0)
    {
    lvReturn += "&" + key + "=" + lvitem.replace("%20", "+");
    }
    else
    {
    lvReturn += key + "=" + lvitem.replace("%20", "+");
    }
    }

    var encoding = "application/x-www-form-urlencoded";

    var SSOAUTH=encodeURIComponent(lvReturn);

    connectorMap.put("SSOAUTH",SSOAUTH);
    connectorMap.put("encoding",encoding);

  • #2
    As an update, I have verified that the query string being created in C# and Java is exactly the same before they are sent. Even used a string compare program to verify. The only thing I cannot verify is how Mirth is sending out the http POST vs how C# sends it. Neither Fiddler nor Wireshark appear to be picking up the outbound message. Last I heard from the vendor, Mirth was double encoding the string after I am manually encoding it and breaking the "+" and "=" in the query parameters. Does anyone know how to force programmatically through javascript the payload so that Mirth doesn't try to re-encode it?

    Comment


    • #3
      Can you post the exported channel?
      Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

      Nicholas Rupley
      Work: 949-237-6069
      Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


      - How do I foo?
      - You just bar.

      Comment


      • #4
        I figured it would come to that but hoped I would gain more understanding of the outbound nature of the http sender first. If you need it to understand what I am asking, I have attached a version that I have redacted all passwords, phi, certificates, and URls from. It also is missing a java jar I compiled that I am using on 2 other interfaces to this vendor(that work), but if you want to at least see what the code is doing here it is.
        Attached Files
        Last edited by ISpdxdc; 03-07-2017, 02:51 PM.

        Comment


        • #5
          I cannot import your channel because I am on a lower version of mirth than 3.4.2
          However, By studying the xml of the channel, I think the problem you are struggling has a very simple solution.

          You are building your urlencoded string in the transformer, which is something you should avoid.

          In the HTTP Sender put application/x-www-form-urlencoded as the content type.

          Provide your query params in the box that is provided. Mirth will automatically construct your encoded url.
          Even before this check the API documentation to see what goes in the header and what else goes in the Query part, and add those values in the appropriate places.
          HL7v2.7 Certified Control Specialist!

          Comment


          • #6
            Indeed, when application/x-www-form-urlencoded is used, the Parameters table will be used. The tool-tip says this as well:



            Regarding the double encoding, from your code it looks like you are encoding it twice:

            Code:
            var lvToken = encodeURIComponent(x.Encode(Cert, Pass, lvReturn));
            Step 1: JAVA CACHE...DID YOU CLEAR ...wait, ding dong the witch is dead?

            Nicholas Rupley
            Work: 949-237-6069
            Always include what Mirth Connect version you're working with. Also include (if applicable) the code you're using and full stacktraces for errors (use CODE tags). Posting your entire channel is helpful as well; make sure to scrub any PHI/passwords first.


            - How do I foo?
            - You just bar.

            Comment


            • #7
              siddharth and Narupley, thx for taking a look at this for me. I may have not been clear previously so let me try to clarify. The first thing I tried was content type = application/x-www-form-urlencoded and then put an unencoded string in query params but Mirth does 2 things, it sends the param name in the message "data" or "Property+1" etc, and the vendor says that breaks the message on their side, and it also encodes the entire query string. The vendor is saying they only want the query params with no param name at the beginning, and they only want the token piece of the params above to be encoded.

              The vendor says this is "standard" for an http request POST. That doesn't sound right to me, but not to belabor the point, if I choose application/x-www-form-urlencoded Mirth forces encoding on the entire query string so I can't send query parameters that look like this (spaces,@, =, etc):

              "[email protected]&PatientId=1234&Timestam p=Thu, 07 Jan 2016 15 01 34 GMT&Token=%3aF7rlE aL99GVbuX8L%2"

              Instead Mirth sends this:
              "UserEmail=test%40test.com&PatientId=1234&Timestam p=Thu%2C+07+Jan+2016+15%3A01%3A34+GMT&Token=%3aF7r lE aL99GVbuX8L%2"


              This is why I am trying to break this encoding scheme with manual encoding, so that I could encode only piece of the query. I still can't get around the query params piece sending the parameter name, and if I choose something like "text/plain" for content type and put the manual encoded string in the content field they say they aren't receiving any string at all, I am guessing they are expecting it for the "query".

              Was I able to clarify the situation better? Can I answer anymore questions on what I am looking for? Again thanks for your help.

              P.S. If I could see what Mirth is actually sending in the http Post exactly how it sends it I could probably debug this better myself. If anyone knows how to either setup Fiddler to analyze Mirth http or a way to log in the channel the actual http post as sent I would still like to know.

              Comment


              • #8
                Originally posted by narupley View Post
                Indeed, when application/x-www-form-urlencoded is used, the Parameters table will be used. The tool-tip says this as well:



                Regarding the double encoding, from your code it looks like you are encoding it twice:

                Code:
                var lvToken = encodeURIComponent(x.Encode(Cert, Pass, lvReturn));

                My clarification above should shed some more light on this.

                Comment


                • #9
                  Fiddler will not be able to capture calls made from mirth. For some reason it fails. I know it because I tried it once, and it never worked. Put Mirth aside for a moment.

                  Use POSTMAN to make mock API calls, keep trying untill you get a 200 as response. Once you have a successful API call, you can easily calibrate that in Mirth. That would give you the right path, and Fiddler captures POSTMAN calls or any REST Client for that matter.
                  HL7v2.7 Certified Control Specialist!

                  Comment


                  • #10
                    I can already do that with the C# version I have written that works. The query string I build in Mirth and the query string I build in C# are identical (checked with string checker). The only difference is that Mirth enforces a coding scheme incompatible with the vendor when you use content type "application/x-www-form-urlencoded". The C version happily sends the query string as created without it re-encoding it regardless of what I set the content-type to.

                    I think for the moment I need a way to build the query string programmatically and without the parameter name at the front. The vendor said he can make his side accept the message if I manually encode the string and set the content-type as "text/plain". If they require query parameters that do not actually conform to a content type of "application/x-www-form-urlencoded", I don't think that is any fault of the HTTP sender in Mirth, but I need a way to build it they way they want it.
                    Last edited by ISpdxdc; 03-08-2017, 07:44 AM.

                    Comment


                    • #11
                      Not sure if this will help But you can create a javascript method in mirth that works like your C# method using java.net.url. There would be an example somewhere on the forums.
                      HL7v2.7 Certified Control Specialist!

                      Comment


                      • #12
                        I figured out what I was doing wrong. Instead of building the string and trying to send the whole thing, I individually setup the "parameter" strings in the parameter piece of the http sender. That fixed the encoding. Now I am receiving a cookie and a redirect and trying to send that back to a browser.... more fun!

                        Comment


                        • #13
                          So my next question is how to send the back the the entire response with the cookies and headers and such to my http listener which is the source? It seems the http sender is intercepting that and then accepting the cookies and only returning a redirect url as a small snippet of HTML. My listener only receives the html portion so the browser I'm trying to send it back to does not receive the cookie to save locally nor redirect to the URL. Basically this is like a proxy. Local webpage hits a mirth http listener, sends to https with encrypted cert as token, receives back a cookie and a redirect. I don't know how to pass that back to the listener and then to the web browser. Any ideas?

                          Comment


                          • #14
                            Well that's what we've been telling you in earlier posts that you need to set params.

                            Now, in order to get cookies from the response you can do that in response transformer by using .getHeaderFields().get("Set-Cookie")

                            http://stackoverflow.com/questions/5...kies-with-java
                            HL7v2.7 Certified Control Specialist!

                            Comment


                            • #15
                              Sorry, I clearly wasn't understanding I needed to break my string up into individual parameters to put into the UI, instead of putting my built string into A parameter. Nonetheless I am getting there. Thanks for the pointers thus far. As for the cookies, did you mean use that in a postprocessor script, or actually the transformer? That example looks like they are writing the connection in Java. Do I have access to the connection and headers from a standard http sender, or were you suggesting I use the java.net.url from your previous post?
                              Last edited by ISpdxdc; 03-13-2017, 08:02 AM.

                              Comment

                              Working...
                              X