mirror of
https://github.com/hoppscotch/hoppscotch.git
synced 2026-04-25 16:55:59 +03:00
[GH-ISSUE #4905] [bug]: Agent inconsistent Content-Type header overrides #1850
Labels
No labels
CodeDay
a11y
browser limited
bug
bug fix
cli
core
critical
design
desktop
discussion
docker
documentation
duplicate
enterprise
feature
feature
fosshack
future
good first issue
hacktoberfest
help wanted
i18n
invalid
major
minor
need information
need testing
not applicable to hoppscotch
not reproducible
pull-request
question
refactor
resolved
sandbox
self-host
spam
stale
testmu
wip
wont fix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hoppscotch#1850
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @qhris on GitHub (Mar 18, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/4905
Originally assigned to: @CuriousCorrelation on GitHub.
Is there an existing issue for this?
Current behavior
Overriding the
Content-Typeheader in the UI results in the web server receiving multipleContent-Typeheaders, which is incorrect behavior.The same behavior happens when using OAuth2 with the agent and clicking "generate token".
Steps to reproduce
Override scenario:
application/jsonwith some dummy data.Content-Typeheader (making sure to use capital letters, since the relay adds a duplicate with lowercase).OAuth2 scenario:
generate token.Content-Typeheaders.Logs and Screenshots
Environment
Production
Hoppscotch Version
Cloud
Interceptor
Agent - Web App
Browsers Affected
Not browser-specific
Operating System
None
Additional Information
I'm observing this behavior with the following:
v2025.2.2using agent0.1.6.e2e5d4f1d5.Additionally, when testing with
https://echo.hoppscotch.ioit incorrectly reports a singleContent-Typeheader, even though multiple were sent. Testing this against my local C# application and logging the headers I can see that hoppscotch agent sends multiple Content-Type headers, in random order.I managed to hack together a workaround in the
preparemethod ofrelay/src/request.rsby checking ifrequest_headerscontains aContent-Typeheader (case insensitive) and removing the content-type header set inContentHandlerto prefer the header coming from the UI.@evanqhuang commented on GitHub (Mar 18, 2025):
Also having the same issue. This is a big problem when trying to run requests that need to override the
Content-Typeheader for request body versioning. E.g.Content-Type application/json;v=2@CuriousCorrelation commented on GitHub (Mar 20, 2025):
Hi @qhris, new Hoppscotch release v2025.2.3, agent v0.1.7, and the desktop app v25.2.3 are out. Could you please check if these updates resolved your issue?
@CuriousCorrelation commented on GitHub (Mar 20, 2025):
@evanqhuang Hi, this issue may now be partially resolved, although overrides may not work fully in all situations, if you do see it fixed, let me know, otherwise this will be fully resolved in one of the upcoming releases.
@qhris commented on GitHub (Mar 20, 2025):
Hey @CuriousCorrelation I can confirm that duplicate headers are no longer sent.
But when overriding the header in the UI with for example
application/json;v=2as mentioned above, approximately 50% of the requests get the incorrectapplication/jsoninstead ofapplication/json;v=2.Using the published
0.1.7agent on hoppscotch cloudv2025.2.3.Not sure if you want me to create a new issue because it still doesn't really fix the override scenario. Here are the relevant logs from my application:
Resulting logs from my local app after sending 12 consecutive requests without any changes from the UI side (just hitting send a couple of times):
@CuriousCorrelation commented on GitHub (Mar 20, 2025):
@qhris Thanks for confirming the duplicate header issue is resolved.
Regarding header overriding - you're right, this remains an issue. For context - this behavior is an artifact of a planned change to how the request construction was handled by the app at fundamental levels which were delayed due to some priority rearrangements, but rest assured it'll be fixed in the upcoming patch release, which is scheduled very soon.
No need to create a separate issue - since this is related to the original problem, we'll keep this issue open to track both concerns.
@CuriousCorrelation commented on GitHub (Mar 20, 2025):
I've updated the issue title to focus on the remaining bug - the inconsistent Content-Type header overrides, this will help track the next stage of fixing the header handling logic.
@qhris commented on GitHub (Mar 31, 2025):
Hey, this is now fixed in version
2025.3.0, closing this issue.