Closed rbeckman-nextgen closed 4 years ago
Build to compare previous behavior MC 3.6.1.b226 Build to verify new behaviors mirthconnect-3.7.0.b2384-unix.tar.gz
Test Steps
{content-length=[18], accept-encoding=[gzip,deflate], connection=[keep-alive], host=[localhost:9000], user-agent=[Apache-HttpClient/4.5.3 (Java/1.8.0_172)], content-type=[text/plain; charset=UTF-8]}
AFTER
{content-length=[18], accept-encoding=[gzip,deflate], connection=[keep-alive], host=[localhost:9000], user-agent=[Apache-HttpClient/4.5.3 (Java/1.8.0_181)], content-type=[text/plain]}
Imported Comment. Original Details: Author: minht Created: 2018-11-21T15:40:15.000-0800
@Simon Are you still around? I am experiencing the exact same issue here. I don't recall if you were able to work-around the issue or upgraded to the fixed version of Mirth Connect.
I'm on the slack channel as Stu.
Cheers
Stewart
Imported Comment. Original Details: Author: stusonmirth Created: 2019-12-02T05:13:16.000-0800
I think I put the content type in a channel map, then included this in the template ${contentType}
Imported Comment. Original Details: Author: seaston Created: 2019-12-02T05:23:58.000-0800
Mirth Connect is sending a charset paramter with the Content-Type header even when application/x-www-form-urlencoded is selected.
According to http://www.iana.org/assignments/media-types/multipart/form-data there are no optional parameters for multipart/form-data
I am trying to interface with a STS that are rejecting the messages from Mirth because the header is being sent like this: Content-Type: application/x-www-form-urlencoded; charset=UTF-8
They say that this is incorrect and should be: Content-Type: application/x-www-form-urlencoded
Their statement is: The parser is doing based on IANA recommendation. Its down to the requester to be in line with what server is asked. It is NOT optional based on IANA to send any other parameters on multipart content type.
Imported Issue. Original Details: Jira Issue Key: MIRTH-4318 Reporter: seaston Created: 2018-08-15T06:32:21.000-0700