Post with application/x-www-form-urlencoded and TEXT body won't pick up environment variables.

[mattisking]

I have checked the following:

• [X] I use the newest version of bruno.
• [X] I've searched existing issues and found nothing related to my issue.

Describe the bug

I have a vendor API that returns tokens for us to use in non-prod environments. The API requires a POST using Content-Type = application/x-www-form-urlencoded and a Body of type TEXT. In the body, if I have something like orderId={{ORDER_ID}} when I post, It literally sends: orderId={{ORDER_ID}} without replacing ORDER_ID from the environment variables. If I remove the Content-Type header, it does replace ORDER_ID as expected: orderId=123456. Removing the Content-Type isn't an option for me as it's not my API.

.bru file to reproduce the bug

meta { name: Demo type: http seq: 1 }

post { url: https://localhost:53245 body: text auth: none }

headers { ~Content-Type: application/x-www-form-urlencoded }

body:text { orderId={{ORDER_ID}} }

script:pre-request { var date = new Date(); var time = date.getTime(); bru.setEnvVar("ORDER_ID", time);

}

Screenshots/Live demo link

Here's the request and result:

Here's a pic of the environment variables:

Note that the fact the URL is junk doesn't matter. You can see in the image on top that {{ORDER_ID}} isn't being substituted from the environment variables.

If I remove the Content-Type header you'll see that it does the replacement:

[jwetzell]

@mattisking I am not able to replicate this in Bruno v1.19. Could you try and see if this issue has been resolved?

[StreetXHasu]

same error. 1.19 windows 11

[mattisking]

Little more straight forward. Wasn't sure I could share some of this but these URL's are public. So based on these: https://developerengine.fisglobal.com/apis/usecomm/eprotect/introduction/getting-started https://developerengine.fisglobal.com/apis/usecomm/eprotect/integrating/testing-certification

goofingaround.zip

Import this whole thing. I cleared out my company bits from it, but you don't need to make a successful call to test it. As long as you see the values get filled.

Note: I have found a workaround that's fine to let me continue but only works because these url's are in a sandbox environment.

[jwetzell]

Seems multipart form is the only body type not working as far as I can tell. This file/section here is the culprit. Looks like bruno is using a pretty dated and not spec compliant library to get FormData in NodeJS. Without switching to something more spec compliant FormData implementation I don't know of way to solve this.

[kumpan-david]

I managed to reproduce this in v1.20.0 by having a variable with backslash \ in it's value. This caused the JSON.parse to fail exactly in the spot @jwetzell pointed out, and because it has an empty catch-block the variable interpolation just gets ignored. Usually NodeJS handles escaping of backslashes from the shell and so does dotenv, so I'm not sure where and why Bruno loads these variables.

[overmind1001]

I was able to reproduce this in v1.27.0. When I include {{password}} Param in "Form URL Encoded" Body it stops substituting "{{password}}" and sends it as is. Password contains double quote mark '"'. If I remove double quote mark then parameter is substituted correctly.

[fcmss]

I was able to reproduce this in Bruno 1.33.1 as well. The variables aren't parsed in the Form URL Encoded fields.