[GH-ISSUE #4905] [bug]: Agent inconsistent Content-Type header overrides #1850

Closed
opened 2026-03-16 22:04:56 +03:00 by kerem · 7 comments
Owner

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?

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

Current behavior

Overriding the Content-Type header in the UI results in the web server receiving multiple Content-Type headers, which is incorrect behavior.

The same behavior happens when using OAuth2 with the agent and clicking "generate token".

Steps to reproduce

Override scenario:

  1. Enable the Hoppscotch Agent in settings.
  2. Set the body content-type of a request to application/json with some dummy data.
  3. Override the Content-Type header (making sure to use capital letters, since the relay adds a duplicate with lowercase).
  4. Send the request and observe undefined behavior.

OAuth2 scenario:

  1. Enable the Hoppscotch Agent in settings.
  2. Configure OAuth2 auhentication for a request (with client_credentials).
  3. Click generate token.
  4. Observe request headers received in backend
  5. In my case, I get a 400 because the backend does not accept multiple Content-Type headers.

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:

  • Running in cloud on v2025.2.2 using agent 0.1.6.
  • Using the self hosted variant on the last commit e2e5d4f1d5.

Additionally, when testing with https://echo.hoppscotch.io it incorrectly reports a single Content-Type header, 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 prepare method of relay/src/request.rs by checking if request_headers contains a Content-Type header (case insensitive) and removing the content-type header set in ContentHandler to prefer the header coming from the UI.

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? - [x] I have searched existing issues and this bug hasn't been reported yet ### Current behavior Overriding the `Content-Type` header in the UI results in the web server receiving multiple `Content-Type` headers, which is incorrect behavior. The same behavior happens when using OAuth2 with the agent and clicking "generate token". ### Steps to reproduce #### Override scenario: 1. Enable the Hoppscotch Agent in settings. 2. Set the body content-type of a request to `application/json` with some dummy data. 3. Override the `Content-Type` header (making sure to use capital letters, since the relay adds a duplicate with lowercase). 4. Send the request and observe undefined behavior. #### OAuth2 scenario: 1. Enable the Hoppscotch Agent in settings. 2. Configure OAuth2 auhentication for a request (with client_credentials). 3. Click `generate token`. 4. Observe request headers received in backend 5. In my case, I get a 400 because the backend does not accept multiple `Content-Type` headers. ### Logs and Screenshots ```shell ``` ### 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: - Running in cloud on `v2025.2.2` using agent `0.1.6`. - Using the self hosted variant on the last commit e2e5d4f1d50c22aa1846e05cbc83abd81949ab2a. Additionally, when testing with `https://echo.hoppscotch.io` it incorrectly reports a single `Content-Type` header, 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 `prepare` method of `relay/src/request.rs` by checking if `request_headers` contains a `Content-Type` header (case insensitive) and removing the content-type header set in `ContentHandler` to prefer the header coming from the UI.
kerem 2026-03-16 22:04:56 +03:00
Author
Owner

@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-Type header for request body versioning. E.g. Content-Type application/json;v=2

<!-- gh-comment-id:2734192370 --> @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-Type` header for request body versioning. E.g. `Content-Type application/json;v=2`
Author
Owner

@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?

<!-- gh-comment-id:2739275444 --> @CuriousCorrelation commented on GitHub (Mar 20, 2025): Hi @qhris, new Hoppscotch release [v2025.2.3](https://github.com/hoppscotch/hoppscotch/releases/tag/2025.2.3), agent [v0.1.7](https://github.com/hoppscotch/agent-releases/releases/tag/v0.1.7), and the desktop app [v25.2.3](https://github.com/hoppscotch/releases/releases/tag/v25.2.3-0) are out. Could you please check if these updates resolved your issue?
Author
Owner

@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.

<!-- gh-comment-id:2739282408 --> @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.
Author
Owner

@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=2 as mentioned above, approximately 50% of the requests get the incorrect application/json instead of application/json;v=2.

Using the published 0.1.7 agent on hoppscotch cloud v2025.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):

[09:46:47 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"]
[09:46:47 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json;v=2]", "[Content-Length, 16]"]
[09:46:48 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"]
[09:46:49 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json;v=2]", "[Content-Length, 16]"]
[09:46:49 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"]
[09:46:49 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"]
[09:46:50 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json;v=2]", "[Content-Length, 16]"]
[09:46:50 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"]
[09:47:01 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json;v=2]", "[Content-Length, 16]"]
[09:47:01 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"]
[09:47:02 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"]
[09:47:02 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"]
<!-- gh-comment-id:2739623601 --> @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=2` as mentioned above, approximately 50% of the requests get the incorrect `application/json` instead of `application/json;v=2`. Using the published `0.1.7` agent on hoppscotch cloud `v2025.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): ``` [09:46:47 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"] [09:46:47 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json;v=2]", "[Content-Length, 16]"] [09:46:48 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"] [09:46:49 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json;v=2]", "[Content-Length, 16]"] [09:46:49 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"] [09:46:49 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"] [09:46:50 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json;v=2]", "[Content-Length, 16]"] [09:46:50 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"] [09:47:01 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json;v=2]", "[Content-Length, 16]"] [09:47:01 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"] [09:47:02 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"] [09:47:02 INF] Request headers: ["[Accept, */*]", "[Host, localhost:5003]", "[Accept-Encoding, deflate, gzip]", "[Content-Type, application/json]", "[Content-Length, 16]"] ```
Author
Owner

@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.

<!-- gh-comment-id:2739802247 --> @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.
Author
Owner

@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.

<!-- gh-comment-id:2739811367 --> @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.
Author
Owner

@qhris commented on GitHub (Mar 31, 2025):

Hey, this is now fixed in version 2025.3.0, closing this issue.

<!-- gh-comment-id:2766130906 --> @qhris commented on GitHub (Mar 31, 2025): Hey, this is now fixed in version `2025.3.0`, closing this issue.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/hoppscotch#1850
No description provided.