Announcement

Collapse
No announcement yet.

Http sender at localhost http web service

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

  • Http sender at localhost http web service

    Hello.
    I have a rest web service developped on my machine, it's url is "http:// localhost/SomeApi/persons". When this channel runs, the destination makes a get request at "/SomeApi/persons" which results in a not authorized error. This is the same if I use 127.0.0.1 instead of localhost.

    I tested with an external API, found somewhere on the internet, and the call is made correct. Why is that? Is there something about mirth that dictates this? I want to see the complete flow of a message which involves multiple destinations, some of which are of type HTTP senders, but no HTTP sender works with calls on the local machine. Why would it refuse to make calls to a perfectly valid web service url and instead cut a piece out of that url?

    I read the whole user guide, is there something in it that I missed?

    Thank you.
    Last edited by common_user; 10-20-2019, 10:48 AM.

  • #2
    I love using Postman to test my APIs. It gives you a TON of control and debugging output so you can see what's going on.

    -= Jack Haines : Founder/CEO of Healthcare Integrations, LLC
    -= [email protected]
    -= Mirth Connect (Advanced)-certified
    -= Gold member of HL7.org
    -= Available for Mirth Connect channel development and consultation! Schedule a FREE call with me at https://calendly.com/jackhaines

    Comment


    • #3
      I did use Postman to test the same API as in the http sender. And it works ok with it, postman receives success status. I compared the same request with postman and mirth and the only difference between the two was the mirth request lacks "http://localhost" from the url. Because of this, it results in not authorized error.

      So now I am trying to understand why mirth alters the url.

      Comment


      • #4
        "localhost" can only be used on the same computer that is running the server. e.g. if you are using postman on the mirth server. if you are using postman on YOUR PC, but the mirth server is different, you must use the server's IP.

        -= Jack Haines : Founder/CEO of Healthcare Integrations, LLC
        -= [email protected]
        -= Mirth Connect (Advanced)-certified
        -= Gold member of HL7.org
        -= Available for Mirth Connect channel development and consultation! Schedule a FREE call with me at https://calendly.com/jackhaines

        Comment


        • #5
          I'm sorry, I did not explain the problem correctly. Both mirth server and the web service are on my computer, the development machine. Also Postman is on the same machine. All of them are on the dev machine.
          The url is the same in both postman and http sender. The problem is, while postman accomplishes the get request successfully, mirth fails and receives unauthorized error. I reproduced both cases with wireshark, and the only difference between them is that in mirth's case, the get is is missing the "http://localhost" from the url. Everything else is the same, headers, query params.

          So my question is why soes mirth decide to alter the url when the url contains localhost or 127.0.0.1?

          By the way, when i test mirt with 127.0.0.1 instead of localhost, it does the same thing and gets the "http://127.0.0.1" out of the url, so it receives the same error.

          The altering of the url is done at message processing time, at channel designing time the url is saved correctly on the destination.

          Comment


          • #6
            Mirth doesn't really care about the IP. I might have an internal IP of "10.2.3.4" but to the internet, It's 45.2.6.13. The IP doesn't affect the innerworkings of the API. I'm not sure what you have going on with your authentication, but it SHOULDN'T have anything to do with what IP it's coming in on...

            -= Jack Haines : Founder/CEO of Healthcare Integrations, LLC
            -= [email protected]
            -= Mirth Connect (Advanced)-certified
            -= Gold member of HL7.org
            -= Available for Mirth Connect channel development and consultation! Schedule a FREE call with me at https://calendly.com/jackhaines

            Comment


            • #7
              https://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html

              Section 5.1.2 explains that it is still a valid request. Mirth (actually apache HttpClient) is sending the abs_path where you are expecting the absoluteURI.

              To allow for transition to absoluteURIs in all requests in future versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI form in requests, even though HTTP/1.1 clients will only generate them in requests to proxies.

              You might need to adjust your authentication to support both.

              Comment


              • #8
                Oh... so you are saying nothing is wrong with the url with absolute path and this might actually be an authentication issue. Well ok. I will investigate this further. Thank you.

                Comment

                Working...
                X