web stats
HTTP Sender - setting multiple Set-Cookie headers on the sender response - Mirth Community

Go Back   Mirth Community > Mirth Connect > Support

Reply
 
Thread Tools Display Modes
  #1  
Old 01-20-2015, 06:22 AM
mark.simmons mark.simmons is offline
What's HL7?
 
Join Date: Oct 2014
Location: Cardiff, Wales, United Kingdom
Posts: 4
mark.simmons is on a distinguished road
Default HTTP Listener - setting multiple Set-Cookie headers on the listener response

Hi,

This is my first post, but I'm trying to follow the guidelines for new threads so please excuse any lack of information or clarity on my question below.

Using Mirth Connect 3.1.1.7461. I haven't posted my channel as it is currently in a mess with multiple versions of different destinations, etc. as I've been trying to fix the issue below. Happy to clean up my channel and post though if that would help over and above my explanation below.

I'm using a single Channel to "transform" a HTTP call from another vendor's product (which is a HTTP POX call) into my products standard HTTP request to invoke/launch our products user interface with user and patient context (the call to our system is a HTTP POST with parameters passed as form data followed by a series of 302 responses and GETs). This will let the user of the other vendors product "launch in context"/invoke our product inside a web browser control in the other vendors product without the user having to login or select the patient again in our product. The outcome I am looking for is to pass back a response to the original request which completely mimics a direct call to our system (i.e. the same response content/body and the same headers and cookies being set). I have to work with the current implementation the other vendor has for configuring links to other systems inside their product.

I have a HTTP Listener source configured and working. It accepts a POST with an XML request body. I parse some values out of the XML and put these in the ChannelMap. I then have a destination which is a Javascript Writer. The Javascript in the destination constructs the HTTP request (with headers, form data, content type, etc.) and POSTs it to our systems standard invocation landing page. The Javascript is based on the very helpful sample provided by @rts in this support forum post.
Side note: While this isn't the reason for this post, I had to use a Javascript writer destination as otherwise I couldn't get access to the 3 Set-Cookie headers which are returned in the response headers from our system. I could only access the last Set-Cookie header pair using a Response mapper mapped to "$('responseHeaders').get('Set-Cookie')" in the the Destination's Response Transformer when I was using a HTTP Sender as the destination type. I had to access the Set-Cookie headers in the Javascript writer via their index values as the httpUrlConnection class also only returned the last cookie if I used getHeaderFields('Set-Cookie'). I have searched but cannot find this as a known issue/bug in JIRA?
The Javascript writer destination then processes the response which is a 302 redirect. The Javascript Writer HTTP connection is set NOT to follow the redirect so I can grab data out of the response and pass this to a second destination. The key part is that I extract the 3 Set-Cookie headers and place the key=value combinations into a ChannelMap variable so I can use this to as the Cookie header on the next call. The other key piece of information extracted is the redirect location into the ChannelMap.

Finally I have a HTTP Sender destination which is configured to call the redirect location from the first destination and pass the 3 cookies on the HTTP request. This works correctly and the destination automatically follows several HTTP 302 redirects before the patient homepage is returned in the final response along with a 200 response code.

The original HTTP Listener source is configured to use the response from my last HTTP Sender destination as the content/body passed back to the other vendors system.

Having explained all that, now I can explain the issue: On the response sent back by the source I have the correct content/body going back, but I also need to send the 3 cookie values (as Set-Cookie headers) back to the other vendor's system so our system will see the user as logged in when they click on links returned in the patient homepage by our system.

The issue is that I can only configure a single Set-Cookie key/value pair in the HTTP Listener response headers. This is a known issue - MIRTH-3449 - which has been fixed and looks like it will be included in 3.2 which is excellent.

However I'm not sure when 3.2 will be released? I assume some month's away given 3.1.1 has just come out and I need to find a workaround for the issue now.

To date as a workaround I've tried passing the 3 cookies as the value of a single Set-Cookie response header with each of the pairs separated by a comma. This apparently was allowed in an older RFC (RFC 2109 I think) but is no longer supported in the current RFC 6265 and the test stub I'm using (POSTMAN as a Chrome extension) doesn't recognise the 2nd and 3rd cookie values. I'm also searched using multiple combinations in Google, the Mirth Support form and other sources to try and find an answer/workaround (hence I stubbled across MIRTH-3449).

I was wondering if anyone could help with a workaround using the existing capabilities in Mirth 3.1.1 (i.e. not applying the fix for MIRTH-3449 as a patch)?

Or if someone could help with some pointers on if and how it is possible to patch my Mirth 3.1.1 to apply the fix for MIRTH-3449?

I am comfortable following Javascript (based on samples like the post above) but patching the actual Mirth code may be a bit beyond my technical skills as I'm an solution architect by trade these days and not a coder (though I'm willing to have a go if I can get some pointers).

Thanks in advance,
Mark.

Last edited by mark.simmons; 01-20-2015 at 06:28 AM. Reason: Modified title to correct connector type from Sender to Listener
Reply With Quote
  #2  
Old 01-20-2015, 06:54 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,097
narupley is on a distinguished road
Default

Well, there is a sort of hack for it in 3.1.1. Use "Set-Cookie" for the first header key, "Set-Cookie<SP>" for the second, and "Set-Cookie<SP><SP>" for the third, and replace the "<SP>" with actual spaces. As long as the originating system doesn't care about the whitespace before the colon in the header, then it should work.



For example, I tested it out in Chrome:




Also, 3.2 is coming soon, on the order of weeks, not months. If you're on support, then we'll be demoing some cool stuff for this month's developer Q&A webinar on Wednesday.
__________________
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.
Reply With Quote
  #3  
Old 01-20-2015, 07:09 AM
mark.simmons mark.simmons is offline
What's HL7?
 
Join Date: Oct 2014
Location: Cardiff, Wales, United Kingdom
Posts: 4
mark.simmons is on a distinguished road
Default

Thanks @narupley that works a treat and my combination of POSTMAN + Chrome doesn't care about the trailing space characters so I can now return the 3 Set-Cookie headers needed.

One side affect is that Wireshark only shows the first of the Set-Cookie headers (it must care about the trailing space) but this isn't an issue as the raw data is available in the HEX dump of the HTTP Response at the bottom of Wireshark if it's needed. Just thought I'd mention it in case it confused someone else.

So good to have an easy solution for this problem as I thought it would end up needing a Mirth patch or something complicated!

Any feedback on my side note from the original post:
Side note: While this isn't the reason for this post, I had to use a Javascript writer destination as otherwise I couldn't get access to the 3 Set-Cookie headers which are returned in the response headers from our system. I could only access the last Set-Cookie header pair using a Response mapper mapped to "$('responseHeaders').get('Set-Cookie')" in the the Destination's Response Transformer when I was using a HTTP Sender as the destination type. I had to access the Set-Cookie headers in the Javascript writer via their index values as the httpUrlConnection class also only returned the last cookie if I used getHeaderFields('Set-Cookie'). I have searched but cannot find this as a known issue/bug in JIRA?
Happy to raise this as a separate thread or log it in JIRA or whatever if needed.

Great to know 3.2 is coming in a matter of weeks! I'm not on support, but working hard to gain acceptance of Mirth inside our organisation so it can be embedded as our integration engine/platform of choice for both HL7 messaging and also the type of synchronous integration I'm trialing with this channel.

Mark.

Last edited by mark.simmons; 01-20-2015 at 07:11 AM.
Reply With Quote
  #4  
Old 01-20-2015, 07:29 AM
narupley's Avatar
narupley narupley is online now
Mirth Employee
 
Join Date: Oct 2010
Posts: 7,097
narupley is on a distinguished road
Default

The reason why "$('responseHeaders').get('Set-Cookie')" only returns the last header is because we put each header in a map one at a time, so later entries with the same key will overwrite previous ones. That has changed now with MIRTH-3449, so you'll be able to grab multiple headers just fine in 3.2.

Regarding the HttpURLConnection part, that's not really part of Mirth Connect per se, it's just part of the built-in Java API. Are you sure you aren't calling getHeaderField instead? According to the docs:

Quote:
getHeaderField

public String getHeaderField(String name)

Returns the value of the named header field.

If called on a connection that sets the same header multiple times with possibly different values, only the last value is returned.

Parameters:
name - the name of a header field.
Returns:
the value of the named header field, or null if there is no such field in the header.
And then here's the getHeaderFields method:

Quote:
getHeaderFields

public Map<String,List<String>> getHeaderFields()

Returns an unmodifiable Map of the header fields. The Map keys are Strings that represent the response-header field names. Each Map value is an unmodifiable List of Strings that represents the corresponding field values.

Returns:
a Map of header fields
Since:
1.4
So, instead you should call getHeaderFields to get the map, then grab the list with the specified key, then iterate through each value in that list. Something like this:

Code:
for each (value in httpUrlConn.getHeaderFields().get('Set-Cookie').toArray()) {
    // Do something
}
Add null-checks and seasoning to taste.
__________________
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.
Reply With Quote
  #5  
Old 01-21-2015, 06:38 AM
mark.simmons mark.simmons is offline
What's HL7?
 
Join Date: Oct 2014
Location: Cardiff, Wales, United Kingdom
Posts: 4
mark.simmons is on a distinguished road
Default

Thanks for that reply.

It's great to know that multiple header values will be fixed by MIRTH-3449 as well and available in 3.2.

You are completely right about the HttpURLConnection - I was initially using getHeaderField and had missed the piece you've highlighted in red above about it only returning the last value.

I switched my Javascript Writer to use getHeaderFields and I'm able to get all 3 values using that. Your example code is better than what I'm doing though so I'll swap to use your approach.

Thanks again for your help and extremely quick replies on this issue. I've been able to do exactly what I need now.

Mark.
Reply With Quote
Reply

Tags
headers, http, listener, response, set-cookie

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -8. The time now is 03:54 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.
Mirth Corporation