rbeckman-nextgen / test-mc6

0 stars 0 forks source link

Mirth Connect HTTP sender adds a charset parameter to the content type application/x-www-form-urlencoded when it is not required #4170

Closed rbeckman-nextgen closed 4 years ago

rbeckman-nextgen commented 4 years ago

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

rbeckman-nextgen commented 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

Imported Comment. Original Details: Author: minht Created: 2018-11-21T15:40:15.000-0800

rbeckman-nextgen commented 4 years ago

@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

rbeckman-nextgen commented 4 years ago

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