Announcement

Collapse
No announcement yet.

manipulating set-cookies responseHeader

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

  • manipulating set-cookies responseHeader

    Hi,

    I have a Patient API call that is working against a url - URL A but not working on URL B. Both of them are on different servers. I am using the HTTP sender.
    It's a weird case, that for URL B I am getting a 200 as responseHeaders, but it's showing as an ERROR with an out-of-context stack trace (below). out-of-context, because I am sending JSON object but the exception is pointing to something else entirely. The patient also shows on the site, but this error is bothering me.

    Upon comparing responses between A and B, I realized that URL B is sending an additional set-cookie in responseHeaders, rest everything else between both the response is same.

    From my understanding, URL B is trying to set a cookie for Mirth, which does not make sense. (This link here says that https://msdn.microsoft.com/en-us/lib...(v=vs.85).aspx)

    Is it possible to delete this set-cookie responseHeader? If not, then where is the problem and what should be done about it?

    Mirth version is 3.5
    Stacktrace

    Code:
    HTTP Sender error
    ERROR MESSAGE: Error connecting to HTTP server
    java.io.EOFException
    	at java.util.zip.GZIPInputStream.readUByte(Unknown Source)
    	at java.util.zip.GZIPInputStream.readUShort(Unknown Source)
    	at java.util.zip.GZIPInputStream.readHeader(Unknown Source)
    	at java.util.zip.GZIPInputStream.<init>(Unknown Source)
    	at java.util.zip.GZIPInputStream.<init>(Unknown Source)
    	at org.apache.http.client.protocol.ResponseContentEncoding$1.create(ResponseContentEncoding.java:67)
    	at org.apache.http.client.entity.LazyDecompressingInputStream.initWrapper(LazyDecompressingInputStream.java:54)
    	at org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:72)
    	at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)
    	at sun.nio.cs.StreamDecoder.implRead(Unknown Source)
    	at sun.nio.cs.StreamDecoder.read(Unknown Source)
    	at java.io.InputStreamReader.read(Unknown Source)
    	at java.io.Reader.read(Unknown Source)
    	at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1928)
    	at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1907)
    	at org.apache.commons.io.IOUtils.copy(IOUtils.java:1884)
    	at org.apache.commons.io.IOUtils.copy(IOUtils.java:1834)
    	at org.apache.commons.io.IOUtils.toString(IOUtils.java:705)
    	at com.mirth.connect.connectors.http.HttpDispatcher.send(HttpDispatcher.java:372)
    	at com.mirth.connect.donkey.server.channel.DestinationConnector.handleSend(DestinationConnector.java:822)
    	at com.mirth.connect.donkey.server.channel.DestinationConnector.process(DestinationConnector.java:476)
    	at com.mirth.connect.donkey.server.channel.DestinationChain.doCall(DestinationChain.java:121)
    	at com.mirth.connect.donkey.server.channel.DestinationChain.call(DestinationChain.java:63)
    	at com.mirth.connect.donkey.server.channel.Channel.process(Channel.java:1716)
    	at com.mirth.connect.donkey.server.channel.Channel.dispatchRawMessage(Channel.java:1191)
    	at com.mirth.connect.donkey.server.channel.SourceConnector.dispatchRawMessage(SourceConnector.java:192)
    	at com.mirth.connect.server.controllers.DonkeyEngineController.dispatchRawMessage(DonkeyEngineController.java:1067)
    	at com.mirth.connect.server.controllers.DonkeyMessageController.reprocessMessages(DonkeyMessageController.java:442)
    	at com.mirth.connect.server.api.servlets.MessageServlet$3.run(MessageServlet.java:209)
    	at java.lang.Thread.run(Unknown Source)
    Please advise.
    Last edited by siddharth; 09-08-2017, 05:44 AM. Reason: added context
    HL7v2.7 Certified Control Specialist!

  • #2
    I saw your post in the chatroom yesterday. You had a nonprintable in a utmvav cookie.

    I had the same issue, there is an SOH (0x01) character in a UTMVAC cookie:
    Code:
    0000: 20 5F 5F 5F 75 74 6D 76 61 63 56 75 4C 59 6C 59 	 ___utmvacVuLYlY
    0010: 42 3D 4D 66 4F 01 4A 67 58 6D 3B                	B=MfO.JgXm;
    The character is 01 and is between O and J.

    The utm cookies seem to be from Google Analytics. That doesn't stop some other service from serving that prefix but it seems unlikely they'd overlap.

    Nick suggested
    You probably don't need to have Include Metadata enabled on your HTTP Sender, assuming you're on a recent version of MC
    This shows up in the connector map variable "responseHeaders".

    I think you might have found a different solution to your problem in the chat room but the root cause seems similar to mine.
    Jon Bartels

    Zen is hiring!!!!
    http://consultzen.com/careers/
    Talented healthcare IT professionals wanted. Engineers to sales to management.
    Good benefits, great working environment, genuinely interesting work.

    Comment


    • #3
      Yeah, It's the same problem. A HEX01 character in cookie caused the message to fail, even though my patient did add in the system, albeit the call returned with 200.
      Nick suggested one other thing

      Code:
      Accept-Encoding: identity
      Adding this in the header part of HTTP Sender, bypasses the problem. Basically, this signals the server, that Mirth (being a client) is not capable of understanding the compression algorithm mentioned, which originally was GZIP.
      https://developer.mozilla.org/en-US/...ccept-Encoding

      I love this community!
      HL7v2.7 Certified Control Specialist!

      Comment

      Working...
      X