starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 01:06:00 +03:00

[GH-ISSUE #4889] [bug]: Random ordering of fields in multipart/form-data #1839

New issue

Closed

opened 2026-03-16 22:01:19 +03:00 by kerem · 11 comments

kerem commented

2026-03-16 22:01:19 +03:00

Owner

Originally created by @emanuel-achirei-deel on GitHub (Mar 14, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4889

Originally assigned to: @CuriousCorrelation on GitHub.

Is there an existing issue for this?

I have searched existing issues and this bug hasn't been reported yet

Current behavior

When I send a multipart/form-data request, the fields always change their order.
Fields should keep the same order as defined in the request.
This is especially impactful for direct S3 uploads as the request fails if some fields are not in the proper order.

Steps to reproduce

Create a dummy server to log fields:

const express = require('express');
const busboy = require('busboy');

const app = express();
const port = 3000;

app.post('/upload', (req, res) => {
  const bb = busboy({ headers: req.headers });
  const fields = [];

  bb.on('field', (name, val) => {
    fields.push({ name, val });
  });

  bb.on('file', (name, file, info) => {
    const { filename, encoding, mimeType } = info;
    fields.push({ name, filename, encoding, mimeType });
    file.resume(); // Discard the file stream
  });

  bb.on('close', () => {
    console.log(fields);
    res.send('Form-data received and logged.');
  });

  req.pipe(bb);
});

app.listen(port, () => {
  console.log(`Server is running on http://localhost:${port}`);
});

Go to Hoppscotch (tested with Web - local interceptor - and Apple Silicon)
Create a multipart/form-data request and add a few fields
Run request sending to local server
Request fields are always shown in a different order
Using curl, fields are always in the same order, so it's not an issue with the testing server

Logs and Screenshots

Environment

Production

Hoppscotch Version

Cloud

Interceptor

Agent - Web App

Browsers Affected

Chrome

Operating System

MacOS

Additional Information

MacOS App version: Version 25.2.2 (20250312.111855)

Originally created by @emanuel-achirei-deel on GitHub (Mar 14, 2025). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4889 Originally assigned to: @CuriousCorrelation on GitHub. ### Is there an existing issue for this? - [x] I have searched existing issues and this bug hasn't been reported yet ### Current behavior When I send a multipart/form-data request, the fields always change their order. Fields should keep the same order as defined in the request. This is especially impactful for direct S3 uploads as the request fails if some fields are not in the proper order. ### Steps to reproduce 1. Create a dummy server to log fields: ``` const express = require('express'); const busboy = require('busboy'); const app = express(); const port = 3000; app.post('/upload', (req, res) => { const bb = busboy({ headers: req.headers }); const fields = []; bb.on('field', (name, val) => { fields.push({ name, val }); }); bb.on('file', (name, file, info) => { const { filename, encoding, mimeType } = info; fields.push({ name, filename, encoding, mimeType }); file.resume(); // Discard the file stream }); bb.on('close', () => { console.log(fields); res.send('Form-data received and logged.'); }); req.pipe(bb); }); app.listen(port, () => { console.log(`Server is running on http://localhost:${port}`); }); ``` 2. Go to Hoppscotch (tested with Web - local interceptor - and Apple Silicon) 3. Create a multipart/form-data request and add a few fields 4. Run request sending to local server 5. Request fields are always shown in a different order 6. Using curl, fields are always in the same order, so it's not an issue with the testing server ### Logs and Screenshots ```shell ``` ### Environment Production ### Hoppscotch Version Cloud ### Interceptor Agent - Web App ### Browsers Affected Chrome ### Operating System MacOS ### Additional Information MacOS App version: Version 25.2.2 (20250312.111855)

kerem

2026-03-16 22:01:19 +03:00

closed this issue
added the
bug

need testing
labels

kerem commented

2026-03-16 22:01:35 +03:00

Author

Owner

@anwarulislam commented on GitHub (Mar 16, 2025):

Hi @emanuel-achirei-deel!
Couldn't reproduce the issue. Can you please send me a screenshot of the body you pass?

@anwarulislam commented on GitHub (Mar 16, 2025): Hi @emanuel-achirei-deel! Couldn't reproduce the issue. Can you please send me a screenshot of the body you pass?

kerem commented

2026-03-16 22:01:40 +03:00

Author

Owner

@emanuel-achirei-deel commented on GitHub (Mar 17, 2025):

@emanuel-achirei-deel commented on GitHub (Mar 17, 2025): <img width="653" alt="Image" src="https://github.com/user-attachments/assets/6f533cfd-8fad-42a5-ab96-f3e84b26a343" />

kerem commented

2026-03-16 22:01:45 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Mar 20, 2025):

Hi @emanuel-achirei-deel, new release along with the new agent v0.1.7 and desktop app v25.2.3 are out, could you please check if it has resolved your issue?

@CuriousCorrelation commented on GitHub (Mar 20, 2025): Hi @emanuel-achirei-deel, new release along with the new agent [v0.1.7](https://github.com/hoppscotch/agent-releases/releases/tag/v0.1.7) and desktop app [v25.2.3](https://github.com/hoppscotch/releases/releases/tag/v25.2.3-0) are out, could you please check if it has resolved your issue?

kerem commented

2026-03-16 22:01:50 +03:00

Author

Owner

@emanuel-achirei-deel commented on GitHub (Mar 26, 2025):

@CuriousCorrelation The issue doesn't seem to be fixed, I still get an error when sending the request about key parameter missing (due to it being after the file field) and as you can see in the screenshot, the order of the fields received by the server doesn't match the order in the request body.

@emanuel-achirei-deel commented on GitHub (Mar 26, 2025): @CuriousCorrelation The issue doesn't seem to be fixed, I still get an error when sending the request about key parameter missing (due to it being after the file field) and as you can see in the screenshot, the order of the fields received by the server doesn't match the order in the request body. <img width="1467" alt="Image" src="https://github.com/user-attachments/assets/b13cf08a-7347-49bd-afae-f990f652c5d0" />

kerem commented

2026-03-16 22:01:55 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Mar 26, 2025):

Hi @emanuel-achirei-deel, thank you for the update. I haven't been able to reproduce this behavior in my testing environment with the agent v0.1.7 or desktop app v25.2.3.

I would appreciate it very much if you could help troubleshoot this further by doing a quick test with an echo server that shows the exact order of post_params and all_params together.

You can use this test requests (just paste into the URL input for easy import):

curl --request POST \
  --url https://echo.qubit.codes/ \
  --header 'content-type: multipart/form-data' \
  --form 1=2 \
  --form 3=4 \
  --form 5=6 \
  --form 7=8

What we are looking for is the order of all_params in the older version (unordered, randomized) vs. the new version (ordered, consistent).

If these test requests show correct ordering but your specific request doesn't, it would be helpful to anonymize your data and try it with the echo server. This would help determine if the issue is with the form data handling in our application or if it might be related to middleware applied around the specific request. Thank you once more!

@CuriousCorrelation commented on GitHub (Mar 26, 2025): Hi @emanuel-achirei-deel, thank you for the update. I haven't been able to reproduce this behavior in my testing environment with the agent v0.1.7 or desktop app v25.2.3. I would appreciate it very much if you could help troubleshoot this further by doing a quick test with an echo server that shows the exact order of `post_params` and `all_params` together. You can use this test requests (just paste into the URL input for easy import): ``` curl --request POST \ --url https://echo.qubit.codes/ \ --header 'content-type: multipart/form-data' \ --form 1=2 \ --form 3=4 \ --form 5=6 \ --form 7=8 ``` What we are looking for is the order of `all_params` in the older version (unordered, randomized) vs. the new version (ordered, consistent). If these test requests show correct ordering but your specific request doesn't, it would be helpful to anonymize your data and try it with the echo server. This would help determine if the issue is with the form data handling in our application or if it might be related to middleware applied around the specific request. Thank you once more!

kerem commented

2026-03-16 22:02:00 +03:00

Author

Owner

@emanuel-achirei-deel commented on GitHub (Mar 28, 2025):

Here's the results @CuriousCorrelation.

If I interpret this correctly, the key parameter is sent as last, even if it's the first in my request

@emanuel-achirei-deel commented on GitHub (Mar 28, 2025): Here's the results @CuriousCorrelation. ![Image](https://github.com/user-attachments/assets/a77c9bdc-3913-42ce-9945-69d084470ee5) If I interpret this correctly, the key parameter is sent as last, even if it's the first in my request

kerem commented

2026-03-16 22:02:05 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Mar 28, 2025):

Hi @emanuel-achirei-deel, thanks for the info. Good news is that I believe I've identified the issue and am working on a proper fix.

The problem previously was in how the Map structure for serialization sometimes led to non-deterministic ordering. And even after the partial fix, there was an unexplored edge case where the map -> obj flattening process introduced another source of unpredictability. JavaScript objects enumerate properties in a specific way - numeric keys first (sorted numerically), then string keys in insertion order. This is why you were seeing fields like "key" appearing at the end after ordered numeric values.

I've completely refactored our approach to be more resilient to this and while the fix still needs to be testing across platforms and request type, from the limited amount of initial testing I did, the issue does seem to be resolved, and it should fix your S3 upload issues.

I'll try to include the fix in the upcoming patch release. Thank you for your patience and detailed testing - it was very helpful for tracking down this subtle but important issue!

@CuriousCorrelation commented on GitHub (Mar 28, 2025): Hi @emanuel-achirei-deel, thanks for the info. Good news is that I believe I've identified the issue and am working on a proper fix. The problem previously was in how the `Map` structure for serialization sometimes led to non-deterministic ordering. And even after the partial fix, there was an unexplored edge case where the `map -> obj` flattening process introduced another source of unpredictability. JavaScript objects enumerate properties in a specific way - numeric keys first (sorted numerically), then string keys in insertion order. This is why you were seeing fields like "key" appearing at the end after ordered numeric values. I've completely refactored our approach to be more resilient to this and while the fix still needs to be testing across platforms and request type, from the limited amount of initial testing I did, the issue does seem to be resolved, and it should fix your S3 upload issues. I'll try to include the fix in the upcoming patch release. Thank you for your patience and detailed testing - it was very helpful for tracking down this subtle but important issue!

kerem commented

2026-03-16 22:02:10 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Apr 10, 2025):

Hi @emanuel-achirei-deel, the latest release v2025.3.1 is out, let me know if the patch has worked for you!

@CuriousCorrelation commented on GitHub (Apr 10, 2025): Hi @emanuel-achirei-deel, the latest release `v2025.3.1` is out, let me know if the patch has worked for you!

kerem commented

2026-03-16 22:02:15 +03:00

Author

Owner

@emanuel-achirei-deel commented on GitHub (Apr 16, 2025):

@CuriousCorrelation just verified, looks to be working, thanks for the fix!

@emanuel-achirei-deel commented on GitHub (Apr 16, 2025): @CuriousCorrelation just verified, looks to be working, thanks for the fix!

kerem commented

2026-03-16 22:02:20 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Apr 16, 2025):

@emanuel-achirei-deel Perfect! Thanks for the confirmation, closing the issue 🚀

@CuriousCorrelation commented on GitHub (Apr 16, 2025): @emanuel-achirei-deel Perfect! Thanks for the confirmation, closing the issue 🚀

kerem commented

2026-03-16 22:02:26 +03:00

Author

Owner

@bart-acc commented on GitHub (Jul 18, 2025):

I did an updated and this problem is back for me. I downgraded to the version I had downloaded (v2025.3.2) ~~and it sends them in order again so it feels like some update after that version broke it again.~~ and it is still broken for me, downgraded to 2025.3.1 and it also didn't work. ~~The order seems stable so I reshuffled them in the UI such that they would end up being sent in the right order.~~ Actually that working the first time I tried seems luck, I've just relabeled them and sort serverside but that's not something I can commit and there will be people who don't have control over what happens serverside.

Maybe just running the installer of a previous version is not enough to downgrade the app fully? It says it's v2025.3.1 but looking at the comments above it obviously worked for some people.

@bart-acc commented on GitHub (Jul 18, 2025): I did an updated and this problem is back for me. I downgraded to the version I had downloaded (v2025.3.2) ~~and it sends them in order again so it feels like some update after that version broke it again.~~ and it is still broken for me, downgraded to 2025.3.1 and it also didn't work. ~~The order seems stable so I reshuffled them in the UI such that they would end up being sent in the right order.~~ Actually that working the first time I tried seems luck, I've just relabeled them and sort serverside but that's not something I can commit and there will be people who don't have control over what happens serverside. Maybe just running the installer of a previous version is not enough to downgrade the app fully? It says it's v2025.3.1 but looking at the comments above it obviously worked for some people.

kerem referenced this issue

2026-03-17 01:07:34 +03:00

[PR #1839] [CLOSED] chore(deps-dev): bump @types/node from 15.14.9 to 16.10.1 #3520