hoppscotch
hoppscotch copied to clipboard
[bug]: multipart/form-data cannot be used to send file since updated
Is there an existing issue for this?
- [x] I have searched existing issues and this bug hasn't been reported yet
Platform
Web App
Browser
Firefox
Operating System
Linux
Bug Description
Since updated latest version, i cannot use to upload file anymore. On BE service, it always return empty/null. It working fine before updated (around 2 or 3 days ago)
is there anyone that found the same issue? how to fix it?
Deployment Type
Hoppscotch Cloud
Version
No response
Indeed. I have the exact environment as yours and my file uploads stopped working. All other fields are submitted as usual; files not.
Same here, please resolve this asap.
@ommz @vipertecpro @mhmmd-iqbal @abraham @silentmatt I'm interested in this issue can you assign me this issue to me.
Feel free to give it a try @techieadi4703.
@ommz @vipertecpro @mhmmd-iqbal @abraham @silentmatt I'm interested in this issue can you assign me this issue to me.
can you look for this issue @jamesgeorge007
I have the exact same issue, only the form data header part arrives at the server.
@mhmmd-iqbal @astudentinearth could you please try turning off the EXPERIMENTAL SCRIPTING SANDBOX option in the settings page and check if the issue is resolved
@nivedin I can upload files with scripting sandbox disabled
@nivedin I can upload files with scripting sandbox disabled
Thank you for confirming. We’re looking into fixing the issue, sorry for the inconvenience.
damn, it took me a lot to find out the issue is from hoppscotch.
Can we have any ETA on this ?
Yesterday i had a meeting with my team, took this as an example to tell them why writing tests are crucial to prevent code regression. well it's open source and they are kind to let us use it anyway. but the thing is i tried hoppscotch.io and the problem is there too. maybe someone should think about that.
I completely understand, and I truly appreciate the effort that goes into maintaining this open-source tool — it’s been incredibly helpful for our team. However, we’re currently quite dependent on this feature for our daily workflow, and at the moment we’re managing through curl requests from the terminal. If possible, could this be looked into on priority? We’re a small team that recently switched from Postman to this tool, and it’s been a great experience so far — we’d really love to continue using it.
@Pezhvak @vipertecpro as I mentioned in the comment above, this issue was introduced with the new experimental scripting flow. Since it’s still an experimental feature, some bugs are expected. You can turn off the EXPERIMENTAL SCRIPTING SANDBOX option from the settings page to fix this issue.
@Pezhvak @vipertecpro as I mentioned in the comment above, this issue was introduced with the new experimental scripting flow. Since it’s still an experimental feature, some bugs are expected. You can turn off the
EXPERIMENTAL SCRIPTING SANDBOXoption from the settings page to fix this issue.
Perfect, thank you so much! This was really helpful, and I’m sorry for overlooking earlier comment.
@nivedin thanks for the clarification, with all due respect it's not about turning it off for me as i stated before i don't expect much from opensource project since we cannot demand when there is nothing paid.
As a feedback i think experimental features should be off by default, specially when it's not tested well like this, it have effected my team workflow and we have switched back to postman since we cannot rely on hoppscotch.
I was considering to purchase the enterprise version of the hoppscotch just to support the project but to be honest it's not well polished at all, kubernetes deployment have bad defaults, i mean real bad defaults like users gets logged out every day and they have to login again, i had to change the defaults to have a reasonable session timeout.
Between updates you have broken the experience a few times. and if i have paid for a license then it would be logical to be pissed of by this kind of broken functionalities and "just go and turn of the experimental feature by yourself because we just broke it for you" would not be acceptable.
Anyway, thanks for all your efforts.
@nivedin thanks for the clarification, with all due respect it's not about turning it off for me as i stated before i don't expect much from opensource project since we cannot demand when there is nothing paid.
As a feedback i think experimental features should be off by default, specially when it's not tested well like this, it have effected my team workflow and we have switched back to postman since we cannot rely on hoppscotch.
I was considering to purchase the enterprise version of the hoppscotch just to support the project but to be honest it's not well polished at all, kubernetes deployment have bad defaults, i mean real bad defaults like users gets logged out every day and they have to login again, i had to change the defaults to have a reasonable session timeout.
Between updates you have broken the experience a few times. and if i have paid for a license then it would be logical to be pissed of by this kind of broken functionalities and "just go and turn of the experimental feature by yourself because we just broke it for you" would not be acceptable.
Anyway, thanks for all your efforts.
Hey @Pezhvak,
Really appreciate you taking the time to share such detailed feedback. I’m truly sorry for the trouble this issue has caused you and your team, this isn’t the kind of experience we want to deliver.
We completely understand your frustration, and we’re actively working on improving the overall stability and polish of Hoppscotch so things like this don’t happen in the future. Your feedback means a lot to us and helps us get better.
Thanks again for your patience and understanding
Hi, based on current priorities and given that this issue is specific to the experimental scripting sandbox (which can be opted out via Settings → Experiments as mentioned above), we're planning to address this in the major release v2025.10.0, expected by the end of this month.
If you have use cases where disabling the sandbox isn't an option and this is blocking your workflow, please let us know. This will help us understand if we need to re-prioritise.
That said, a patch release at this point would mean:
- The Desktop App release would be deferred due to certain internal blockers and remain another version behind (it's already one release behind, and we're working to streamline this with the major release)
- Diverting bandwidth from active projects, given the overhead for monitoring deployment jobs and staying on track with the monthly release roadmap
We want to be transparent about these trade-offs as we evaluate priorities.
Yesterday i had a meeting with my team, took this as an example to tell them why writing tests are crucial to prevent code regression
@Pezhvak, thanks for bringing this up. We maintain strict unit test coverage for packages with isolated logic (like @hoppscotch/js-sandbox), and have e2e tests for @hoppscotch/cli since it's easier to test in that environment. However, shared packages like @hoppscotch/common targeting web/desktop platforms haven't had the same level of coverage. This is something we're aware of and working to improve - it hasn't been consistently followed due to shipping priorities and the surface area involved, but we recognize the gap.
As a feedback i think experimental features should be off by default, specially when it's not tested well like this
You're absolutely right that experimental features are typically off by default. We enabled the new scripting sandbox by default specifically to gather community feedback quickly and iterate on the new capabilities. The opt-out was intentional to maximize real-world testing with the ability to opt out. However, given the impact this has had on workflows, we'll re-evaluate this approach for future experimental features to strike a better balance between gathering feedback and maintaining stability.
I was considering to purchase the enterprise version of the hoppscotch just to support the project but to be honest it's not well polished at all, kubernetes deployment have bad defaults, i mean real bad defaults like users gets logged out every day and they have to login again, i had to change the defaults to have a reasonable session timeout.
These are really valuable insights. Please consider:
- Email: Reach out to us at [email protected] with the specific issues you've faced
- GitHub Issue: Create a dedicated issue detailing your Enterprise deployment concerns so we can track and address them
Your real-world experience with the Enterprise setup would be really helpful in improving the product's stability and polish.
We'll post an update here once v2025.10.0 is released with the fix. If you have concerns about the timeline or the workaround doesn't work for your use case, let us know.
Quick update: A PR #5512 has been raised to address this issue concerning file uploads in the experimental scripting sandbox and is scheduled for the upcoming major release.
Closing this as the above fix is now live in v2025.10.0. You can try the latest scripting improvements by enabling the Experimental scripting sandbox in settings. Please refer to the documentation for details.
Also, a quick note on the ongoing scripting improvements (RFC). We recently added chai-powered assertions and Postman script import support (#5417).
Please note: We don't recommend migrating existing scripts yet, as breaking changes are expected. The rollout is intentionally gradual to gather feedback and iterate. Your input will be invaluable in shaping the next generation of Hoppscotch scripting!
