Error when trying to send a request with a multipart file through Bruno

[jan-sieradzki]

I have checked the following:

• I have searched existing issues and found nothing related to my issue.

This bug is:

• making Bruno unusable for me
• slowing me down but I'm able to continue working
• annoying
• this feature was working in a previous version but is broken in the current release.

Bruno version

3.0.2

Operating System

macOS 26.2

Describe the bug

When I try to send a request containing a multipart file in the body, the file uploaded from the GUI is likely not included in the request at all, resulting in a MissingServletRequestPartException being thrown with the message Required part 'file' is not present and a 400 Bad Request response being returned. The same request executed by curl works correctly.

.bru file to reproduce the bug

meta {
name: Send multipart file
type: http
seq: 1
}

post {
url: {{url}}/files
body: multipartForm
auth: inherit
}

headers {
Accept: application/json
}

body:multipart-form {
file:
}

Screenshots/Live demo link

[shubh-bruno]

Thanks for reporting @jan-sieradzki we will look into this issue

[shubh-bruno]

Hi @jan-sieradzki

I’m trying to reproduce the issue on my side so we can narrow down what’s going wrong in Bruno 3.0.2. Could you please share a bit more info?

1. File details

   • What’s the file size and file type you’re uploading?
   • If possible, could you share a small sample file that reproduces the problem?

2. Server / endpoint MVP

   • Could you share a minimal server example (or request spec) for the /upload endpoint you’re hitting?
   • Specifically: expected multipart field name (e.g. file), and any required headers/auth.

3. .bru file vs UI behavior

   • When you attach the file in the UI, is the issue that the .bru file doesn’t update with the path, or that the file is not actually included in the outgoing request?
   • Also: did you ever manually edit the file: line in the .bru file, or was it only set via the UI?

4. Request inspection

• If possible, could you record a short screen capture with the Inspect tab / request details open, from selecting the file all the way until you get the response/error?
• Seeing the raw multipart request (or generated curl) would help a lot.

[jan-sieradzki]

Hi @shubh-bruno

let me try to provide you with as much additional information as I can:

1. I believe that the size, type and details of the file are irrelevant to my problem, as I experienced it while testing the endpoint on simple, small .txt and .csv files.
2. We are experiencing this issue in our Spring Boot application with an endpoint that expects a MultipartFile. Here are more details about the specific request with some less important elements (url and path) removed:

post {
  url: url
  body: multipartForm
  auth: inherit
}

headers {
  Authorization: Bearer {{token}}
  Accept: application/json
}

body:multipart-form {
  file: @file(path)
}

3. We do not expect the .bru file to update with the path to the loaded file. The problem clearly comes from the fact that the file is not being sent correctly in the request by Bruno. We did not try to edit the .bru file with a specific path, as it would not make sense in our case, we only used the UI.
4. Here is the curl generated by Bruno, again with some elements removed:

curl --request POST \
  --url url \
  --header 'accept: application/json' \
  --header 'authorization: Bearer {{token}}' \
  --header 'content-type: multipart/form-data' \
  --form file=@path

I am also attaching network logs (also some information removed):



Preparing request to url
Current time is 2026-01-09T09:49:41.692Z
POST url
Accept: application/json
Content-Type: multipart/form-data; boundary=--------------------------38dacbca10f8ca9ae7760d92
User-Agent: bruno-runtime/3.0.2
Authorization: Bearer 
{
  "_overheadLength": 148,
  "_valueLength": 0,
  "_valuesToMeasure": [
    {
      "fd": null,
      "path": path,
      "flags": "r",
      "mode": 438,
      "end": null,
      "bytesRead": 0,
      "_events": {},
      "_readableState": {
        "highWaterMark": 65536,
        "buffer": [],
        "bufferIndex": 0,
        "length": 0,
        "pipes": [],
        "awaitDrainWriters": null
      },
      "_eventsCount": 3
    }
  ],
  "writable": false,
  "readable": true,
  "dataSize": 0,
  "maxDataSize": 2097152,
  "pauseStreams": true,
  "_released": false,
  "_streams": [
    "----------------------------38dacbca10f8ca9ae7760d92\r\nContent-Disposition: form-data; name=\"file\"; filename=\"file.csv\"\r\nContent-Type: text/csv\r\n\r\n",
    {
      "source": {
        "fd": null,
        "path": path,
        "flags": "r",
        "mode": 438,
        "end": null,
        "bytesRead": 0,
        "_events": {},
        "_readableState": {
          "highWaterMark": 65536,
          "buffer": [],
          "bufferIndex": 0,
          "length": 0,
          "pipes": [],
          "awaitDrainWriters": null
        },
        "_eventsCount": 3
      },
      "dataSize": 0,
      "maxDataSize": null,
      "pauseStream": true,
      "_maxDataSizeExceeded": false,
      "_released": false,
      "_bufferedEvents": [
        {
          "0": "pause"
        }
      ],
      "_events": {},
      "_eventsCount": 1
    },
    null
  ],
  "_currentStream": null,
  "_insideLoop": false,
  "_pendingNext": false,
  "_boundary": "--------------------------38dacbca10f8ca9ae7760d92"
}
SSL validation: disabled
Using proxy: url
there was an error executing the request!
HTTP/1.1 400 Bad Request
cache-control: no-cache, no-store, max-age=0, must-revalidate
content-type: application/problem+json
date: Fri, 09 Jan 2026 09:49:46 GMT
expires: 0
pragma: no-cache
server: envoy
strict-transport-security: max-age=31536000 ; includeSubDomains
vary: Origin,Access-Control-Request-Method,Access-Control-Request-Headers
x-amzn-requestid: id
x-content-type-options: nosniff
x-envoy-upstream-service-time: 593
x-frame-options: DENY
x-xss-protection: 0
connection: close
transfer-encoding: chunked
request-duration: 4366
"[object Object]"

I hope this helps you track down the error.

[sid-bruno]

@jan-sieradzki
Sorry but we'll need a little more help from you.

Were you able to run the same with something like curl or something else for the same endpoint. A minimal reproduction of the upload server would help us debug better since the one's were using for testing seem to be working as expected.

[jan-sieradzki]

Yes, when I executed the same request using curl, everything worked normally. The problem only affects requests executed by Bruno, but since you say it works for you, I will try to verify the setup on our side that may be causing the issue.

[sid-bruno]

Yes, when I executed the same request using curl, everything worked normally. The problem only affects requests executed by Bruno, but since you say it works for you, I will try to verify the setup on our side that may be causing the issue.

if it isn't too much of an ask, if you can pass on a minimal reproduction of the server being used, that'd help as well

[jan-sieradzki]

It would be difficult to share the exact setup of our application, but I tried to reproduce the issue on a separate, simple Spring Boot application with an endpoint that accepts files, and everything worked fine there. In our target solution, we use Bruno through a local proxy, and I thought that might be the source of the problem, so if there is anything else you could verify, it would be that.

[sid-bruno]

I can probably look into the proxy, but you can configure the proxy settings in the collection as well to see if that was the blocker.

In case you need references for it

• https://blog.usebruno.com/simplifying-proxies-and-bruno-integration
• https://docs.usebruno.com/configure/settings#proxy

[jan-sieradzki]

All right, thank you.

[dazhuangge]

[dazhuangge]

curl --request POST
--url https://httpbin.org/post
--header 'content-type: multipart/form-data'
--form 'myfile=@C:\Program Files\Bruno\icudtl.dat'

[sid-bruno]

@dazhuangge would need more details

• How large is the file ?
• Did it actually end at some point or it stayed on the loading state forever?

[sid-bruno]

@jan-sieradzki , Closing this for now, if the issue persists, please re-open the issue