You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
When using the Query Parameters section of the HTTP Sender connector, the parameters can be sent out of order. This breaks some APIs that require a specific order for parameters. In my particular use case, the API I'm trying to communicate with requires me to use HMAC to hash the URI. If that hash doesn't match exactly to the full URI actually sent, it will reject the request.
To Reproduce
Setup an echo server somewhere (i.e. npx http-echo-server)
Create a channel with an http sender connector to send to your echo server URL
Add multiple query parameters using the table (i.e. "start_date", "end_date", "app_id"). Use any values
Steps to reproduce the behavior:
Send a message through your channel
Observe the output in the console for your echo server
See that the parameters are not in the order you set them
Expected behavior
The destination connector should preserve the order of the parameters as entered.
Actual behavior
The parameters are not in the order entered in the UI.
Environment (please complete the following information):
OS: Rocky Linux 8, CentOS 7
Java Distribution/Version OpenJDK. 17
Connect Version 3.12-4.5
Workaround(s)
I have to manually build my URL string, store it on the channel map and use that as my http URL on the connector, not using any query parameters on the UI.
Additional context
It doesn't matter if you tell the connector to use the table or use a map variable. The behavior is the same.
I even tried a LinkedHashMap to attempt to force the order.
The code appears to be creating a new map from the existing map here:
Example Code
Here is an example of where I tried to use a LinkedHashMap to force the order:
varLinkedHashMap=Packages.java.util.LinkedHashMap;// Create a new LinkedHashMap instancevarorderedMap=newLinkedHashMap();orderedMap.put('app_id','uuid----------');orderedMap.put('phi_level','high');orderedMap.put('start_date','2024-08-01');orderedMap.put('end_date','2024-08-31');orderedMap.put('demographics_detail','high');orderedMap.put('patient_status_detail','high');
And the corresponding output from my echo server: /?end_date=2024-08-31&phi_level=high&patient_status_detail=high&demographics_detail=high&app_id=uuid----------&start_date=2024-08-01 HTTP/1.1
The text was updated successfully, but these errors were encountered:
Describe the bug
When using the Query Parameters section of the HTTP Sender connector, the parameters can be sent out of order. This breaks some APIs that require a specific order for parameters. In my particular use case, the API I'm trying to communicate with requires me to use HMAC to hash the URI. If that hash doesn't match exactly to the full URI actually sent, it will reject the request.
To Reproduce
npx http-echo-server
)Steps to reproduce the behavior:
Expected behavior
The destination connector should preserve the order of the parameters as entered.
Actual behavior
The parameters are not in the order entered in the UI.
Environment (please complete the following information):
Workaround(s)
I have to manually build my URL string, store it on the channel map and use that as my http URL on the connector, not using any query parameters on the UI.
Additional context
It doesn't matter if you tell the connector to use the table or use a map variable. The behavior is the same.
I even tried a LinkedHashMap to attempt to force the order.
The code appears to be creating a new map from the existing map here:
connect/core-util/src/com/mirth/connect/util/HttpUtil.java
Line 106 in be90435
Example Code
Here is an example of where I tried to use a LinkedHashMap to force the order:
And the corresponding output from my echo server:
/?end_date=2024-08-31&phi_level=high&patient_status_detail=high&demographics_detail=high&app_id=uuid----------&start_date=2024-08-01 HTTP/1.1
The text was updated successfully, but these errors were encountered: