[PR #4951] [MERGED] fix(web): add explicit headers following prior normalization #4996

New issue

Closed

opened 2026-03-17 02:29:12 +03:00 by kerem · 0 comments

kerem commented

2026-03-17 02:29:12 +03:00

Owner

📋 Pull Request Information

Original PR: https://github.com/hoppscotch/hoppscotch/pull/4951
Author: @CuriousCorrelation
Created: 4/1/2025
Status: ✅ Merged
Merged: 4/4/2025
Merged by: @jamesgeorge007

Base: patch ← Head: fix-refactor-common-source-relay-call

📝 Commits (1)

6a57188 fix(web): add explicit headers following prior normalization

📊 Changes

1 file changed (+10 additions, -0 deletions)

View changed files

📝 packages/hoppscotch-selfhost-web/src/platform/auth/desktop/index.ts (+10 -0)

📄 Description

These changes add explicit Content-Type headers to direct (via native interceptor) authentication requests after changes made in PR #4931 that modified how Content-Type headers are handled in the relay plugin.

Closes HFE-799
Closes #4949

In issue #4905, that was about Hoppscotch Agent and Native interceptor inconsistently handling Content-Type headers. The issue had two main manifestations, duplicate headers - when overriding the Content-Type header in the UI or using OAuth2 authentication, the agent would send multiple Content-Type headers to the web server. This caused undefined behavior and often 400 errors for backends that don't accept duplicate headers. And inconsistent overrides - even when the content type was explicitly set (for example to application/json;v=2), the agent/native would inconsistently apply this override. Server logs revealed that roughly 50% of requests would use the correct override value, while the others would revert to the default application/json.

The two-part solution implemented first in PR #4911 addressed the duplicate headers issue by implementing header normalization before final relay. This prevented duplicate headers with different casing from being sent and PR #4931 then resolved the inconsistent override behavior by removing the automatic Content-Type header insertion in the ContentHandler component. As explained in the PR description, this was a temporary workaround until we implement a HTTP/2-compliant solution with proper normalization.

While the fixes in PR #4911 and #4931 correctly resolved the header inconsistency issues for general API requests, they introduced a new problem: requests that previously relied on the automatic Content-Type insertion now have no Content-Type header at all.

This mainly affects direct calls around authentication flows in the desktop module, which were using the content.json() functionality without explicitly setting Content-Type headers, relying on the automatic insertion that has now been removed.

These changes add the now-required explicit Content-Type headers to three authentication-related API calls in the desktop platform module:

The initial user details GraphQL query:

headers: {
  Authorization: `Bearer ${accessToken}`,
  "Content-Type": "application/json",
},

The magic link email submission endpoint:

headers: {
  "Content-Type": "application/json",
},

The token verification endpoint:

headers: {
  "Content-Type": "application/json",
},

This will make sure that authentication flows continue to work properly with the native interceptor after the header handling changes.

As noted in PR #4931, this is considered a temporary solution. The plan is to revisit the content-type handling when we implement a more comprehensive HTTP/2-compliant header normalization system in the kernel layer.

While HTTP/1.1 headers are case-insensitive per RFC 7230, inconsistent handling across server implementations can treat differently-cased variations as distinct headers. HTTP/2 (RFC 7540) mandates converting all header field names to lowercase, which would prevent these issues altogether. In such cases, relying fully on MediaType interface from the kernel will help handling these edge-cases.

Notes to reviewers

docker compose --profile default up to setup AIO then pnpm dev:full in packages/hoppscotch-desktop to launch sh-desktop to test out the login flow.

Demo

https://github.com/user-attachments/assets/5eac6142-5a28-48be-b6bd-46f738ef49a0

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/hoppscotch/hoppscotch/pull/4951 **Author:** [@CuriousCorrelation](https://github.com/CuriousCorrelation) **Created:** 4/1/2025 **Status:** ✅ Merged **Merged:** 4/4/2025 **Merged by:** [@jamesgeorge007](https://github.com/jamesgeorge007) **Base:** `patch` ← **Head:** `fix-refactor-common-source-relay-call` --- ### 📝 Commits (1) - [`6a57188`](https://github.com/hoppscotch/hoppscotch/commit/6a57188a08ed704190634945abbf29f7422ae6b2) fix(web): add explicit headers following prior normalization ### 📊 Changes **1 file changed** (+10 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `packages/hoppscotch-selfhost-web/src/platform/auth/desktop/index.ts` (+10 -0) </details> ### 📄 Description These changes add explicit `Content-Type` headers to direct (via `native` interceptor) authentication requests after changes made in [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931) that modified how `Content-Type` headers are handled in the `relay` plugin. Closes HFE-799 Closes #4949 In [issue #4905](https://github.com/hoppscotch/hoppscotch/issues/4905), that was about Hoppscotch Agent and Native interceptor inconsistently handling `Content-Type` headers. The issue had two main manifestations, duplicate headers - when overriding the `Content-Type` header in the UI or using OAuth2 authentication, the agent would send multiple `Content-Type` headers to the web server. This caused undefined behavior and often 400 errors for backends that don't accept duplicate headers. And inconsistent overrides - even when the content type was explicitly set (for example to `application/json;v=2`), the agent/native would inconsistently apply this override. Server logs revealed that roughly 50% of requests would use the correct override value, while the others would revert to the default `application/json`. The two-part solution implemented first in [PR #4911](https://github.com/hoppscotch/hoppscotch/pull/4911) addressed the duplicate headers issue by implementing header normalization before final relay. This prevented duplicate headers with different casing from being sent and [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931) then resolved the inconsistent override behavior by removing the automatic `Content-Type` header insertion in the `ContentHandler` component. As explained in the PR description, this was a temporary workaround until we implement a HTTP/2-compliant solution with proper normalization. While the fixes in PR #4911 and #4931 correctly resolved the header inconsistency issues for general API requests, they introduced a new problem: **requests that previously relied on the automatic `Content-Type` insertion now have no `Content-Type` header at all**. This mainly affects direct calls around authentication flows in the desktop module, which were using the `content.json()` functionality without explicitly setting `Content-Type` headers, relying on the automatic insertion that has now been removed. These changes add the now-required explicit `Content-Type` headers to three authentication-related API calls in the desktop platform module: - **The initial user details GraphQL query**: ```javascript headers: { Authorization: `Bearer ${accessToken}`, "Content-Type": "application/json", }, ``` - **The magic link email submission endpoint**: ```javascript headers: { "Content-Type": "application/json", }, ``` - **The token verification endpoint**: ```javascript headers: { "Content-Type": "application/json", }, ``` This will make sure that authentication flows continue to work properly with the native interceptor after the header handling changes. As noted in [PR #4931](https://github.com/hoppscotch/hoppscotch/pull/4931), this is considered a **temporary solution**. The plan is to revisit the content-type handling when we implement a more comprehensive HTTP/2-compliant header normalization system in the kernel layer. While HTTP/1.1 headers are case-insensitive per [RFC 7230](https://tools.ietf.org/html/rfc7230), inconsistent handling across server implementations can treat differently-cased variations as distinct headers. HTTP/2 ([RFC 7540](https://tools.ietf.org/html/rfc7540)) mandates converting all header field names to lowercase, which would prevent these issues altogether. In such cases, relying fully on `MediaType` interface from the kernel will help handling these edge-cases. #### Notes to reviewers `docker compose --profile default up` to setup AIO then `pnpm dev:full` in `packages/hoppscotch-desktop` to launch sh-desktop to test out the login flow. #### Demo https://github.com/user-attachments/assets/5eac6142-5a28-48be-b6bd-46f738ef49a0 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>