Sending files using a multipart/form-data request fails (since 1.37.0)

[bbak]

I have checked the following:

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

Describe the bug

I've a collection that uploads some Json files to some service, which was working flawlessly with 1.36.x but doesn't in 1.37.0.

Bruno's error message is this:
Error invoking remote method 'send-http-request': TypeError: data should be a string, Buffer or Uint8Array

Adding a content-type ( @contentType(application/json) ) does not change the behavior.

.bru file to reproduce the bug

meta {
name: Some Name
type: http
seq: 1
}

post {
url: https://some.target.url/api/receive
body: multipartForm
auth: inherit
}

headers {
Content-Type: multipart/form-data
}

body:multipart-form {
id: 65e62dabcd3c585015b9f56f
data: @file(C:\Temp\bruno_upload\some_file.json)
}

Screenshots/Live demo link

[mesopotamiaMD]

I'm a user and have just seen your case, as I have had a similar issue. In my case, it worked when i used relative path

sourceFile: @file(../../Jobsfolder/test.txt)

but you have to change it over the file mode.

The relative path is added to the installation path, which makes no sense and needs to be fixed. Regards...

[bbak]

Ah, interesting. Thanks.

Yet I believe, when using the UI to select a file, the absolute Path is written to the .bru file. Hence it needs to be fixed anyways.

[ganesh-bruno]

Hey @bbak

Thanks for reporting this issue.

I tried to reproduce it with version 1.37.0, adding the json file to the body/multipart and setting the Content-Type: multipart/form-data` header, as you mentioned. It seems to be working fine on my end.

Could you try removing the auth and header settings, and then check again to see if it works for you?

If the issue still persists after removing those, would it be possible for you to share a video or screenshot of the issue? This will help us understand if we're on the same page or if I missed something while reproducing it.

3723.mov

[bbak]

Hey, I already see a difference: I run Bruno in Developer Mode, since I need access to the filesystem. And I actually wonder how you can add a file from the filesystem while being in Safe (Sandbox) Mode. Anyway, here's a Video:

Bruno.2025-01-07.mp4

[bbak]

Still present in 1.38.0

Changing to Safe Mode yields the same behaviour.

[bill-wirz-iw]

I have also seen this behaviour. I was able to send a file using the Content-Type: multipart/data header (what @ganesh-bruno used). However, the data was not formatted with the correct boundaries and was rejected by the API. However, Content-Type: multipart/form-data does not work (same error as @bbak)

[flleonx]

I'm experiencing the same problems as @bbak and @bill-wirz-iw in version 1.38.0

[helloanoop]

@lohit-bruno Please look into this

[PAllisonVSO]

It there a way to install an older snap version of bruno until this is fixed. I am trying to use bruno to automate some testing (yay!), but this is a stopping point at the moment.

I did find the bruno CLI is still working! So, I can use it for the moment, just makes testing in the app a bit more cumbersome

[fadunco]

Same issue here on 1.38.0, downgraded to 1.36.1 manually and it worked straightaway

[bbak]

@PAllisonVSO If you are on Windows, you can prevent the upgrade.

Bruno's Upgrade Files reside in C:\Users\<your User>\AppData\Local\bruno-updater.

So, if you install 1.36.1, open it, do your stuff, and before closing Bruno delete the contents of that folder, the upgrade fails and next time Bruno starts, it's still 1.36.1.

I'm pretty sure, it's similar on other OSs.

[PAllisonVSO]

@bbak Thanks, but snap is a WSL2 tool. For Windows, you just turn off auto-updates and it won't upgrade automatically (Collection -> Preferences -> About: uncheck 'Automatically download and install updates'). My problem under WSL2 is that snap does not have previous versions available, only the latest.

I use it under WSL2 because all my development is in the Linux subsystem, and it runs much faster and more stable there due to collection monitoring.

EDIT: I was able to download the 1.36.1 debian package from the release page, I tried to install it sudo dpkg -i <name of package>.deb and it said it failed, but it did back-date my WSL2 bruno to 1.36.1 and the file upload works!

[FraCata00]

Same issue here on 1.38.1 AUR version -> bruno-bin
@lohxt1 I hope the maintainers merge your PR soon

[bbak]

@PAllisonVSO Turning that off in 1.36.1 did not do what it is intended for. I believe that flag/checkbox started working in 1.37.0.

I falsely assumed that this was the background of your question. Sorry.

[CrowbarKZ]

Same issue here, downgrading to 1.36.1 fixed it.

[helloanoop]

Merged #3795 with the fixes. This is set to go out in v1.39.0 scheduled to go out on 5 Feb 2025

[FraCata00]

Merged #3795 with the fixes. This is set to go out in v1.39.0 scheduled to go out on 5 Feb 2025

sounds good!

[brycethornton]

I just ran into this and found this issue. To work around the issue I just changed the header name from Content-Type to content-type (lowercase). It appears the fix deals with this casing issue so give this a shot if you don't want to downgrade.

[anusree-bruno]

Hey everyone!

We've fixed this issue in our latest nightly build. Feel free to check it out and let us know if it works for you!

[Pencilbox]

Still have a problem with bruno_1.39.0-2025.2.6_x64_win.exe with content-type: multipart/form-data; but with content-type: json it works.

[PXNX]

Unlike latest stable (1.38.0), the latest nightly (bruno_1.39.0-2025.2.6_x64_win) works fine (just crashed my server lol). Thanks for fixing it <3

[reithal]

@brycethornton Thank you! That worked for me too. Can't update yet to latest .. I am on 1.38.1.

[ParkerHGordon]

Updating to 1.39 worked for my coworker who was having the same issue on his Windows machine.

[bbak]

@ParkerHGordon Indeed. v1.39 was supposed to deliver the fix for this. I can also confirm it's now working again.