Co-authored-by: James George <25279263+jamesgeorge007@users.noreply.github.com>
Co-authored-by: Nahid Hasan <52489202+nahidhasan94@users.noreply.github.com>
Add per-domain toggle to disable automatic HTTP redirect following in
the Native and Agent interceptors. When disabled, requests return the
redirect response (status code, headers, body) without following the
Location header.
Previously HTTP redirects were always followed (on browser, can't do
much about that, see
https://fetch.spec.whatwg.org/#atomic-http-redirect-handling) without
option to inspect the redirect response itself. This prevented
developers from accessing redirect metadata needed when testing OAuth
flows (PKCE where intermediate responses contain authorization tokens),
authentication endpoints that return codes in Location headers with 302
status, and debugging API redirect chains. But on the desktop app,
redirects were just never followed, creating the opposite effect.
The browser's fetch API applies atomic HTTP redirect handling per spec,
making it impossible to intercept redirects and inspect their responses.
The Native and Agent interceptors use curl and native HTTP clients
respectively, both supporting redirect control, making this feature
viable for these specific interceptors. (Proxyscotch tbd).
Updates `tauri-plugin-shell` from vulnerable version to `v2.2.1` to
address `CVE-2025-31477` in `open` around scope validation.
Affects both `hoppscotch-agent` and `hoppscotch-desktop`.
Closes FE-1022
This implements backend path management, backup system, cross-platform utilities, and refactors the `appload` plugin arch to support portable mode deployment.
The changes are mainly establishing foundational infra maintaining current frontend behavior until phase-3+ integration.
- This standardises package versions between desktop, agent, appload, relay
all the native components to resolve version inconsistencies and prepare
for unified bumps in the future.
- Account for recent minor dependency bumps as a follow-up to #5329
Co-authored-by: jamesgeorge007 <25279263+jamesgeorge007@users.noreply.github.com>
This fixes file uploads incorrectly showing MIME type as "Other" instead
of their actual content types by expanding the `MediaType` enum relay
to include common audio, video, and image formats.
Basically `MediaType` enum is used for both `ContentType` which would
map to `ContentType` from `hoppscotch-data` (e.g. `multipart/form-data`)
but also to `FormValue` in `interop`
```rust
pub enum FormValue {
...
File {
filename: String,
content_type: MediaType,
data: Bytes,
},
}
```
although the later should be much more pervasive.
This is a follow up on #5244
Closes FE-887
Closes#3810Closes#5223Closes#5233
The issue occurred because the `relay`'s `MediaType` couldn't deserialize
beyond the basic types (text, JSON, XML, etc.), lacked support for
other media file types. The TypeScript layer correctly detected MIME
types (e.g., "audio/x-m4a"), but the deserialization process fell back
to `MediaType::Other`. Main reason for servers performing strict MIME
validation to reject uploads.
This adds documentation for the Hoppscotch Agent package covering
installation, configuration, and usage.
Closes FE-942
Closes#5284
The agent package lacked user-facing documentation beyond the minimal
Tauri template content. Users needed guidance for installation,
registration, certificate management, proxy configuration, and
troubleshooting.
This updates `vue-tsc` to version `2.2.0` and removes caret prefix from
TypeScript to resolve build compatibility issues that were preventing
builds in `agent`'s CI/CD pipeline.
The build process was failing with "Search string not found" errors when
vue-tsc attempted to patch TypeScript's internal structure.
Initially thought to be related to FE-925, FE-924.
Closes FE-926
The previous config used `TypeScript` at `^5.8.3` with `vue-tsc` at
`^2.1.6`. The `vue-tsc` package contains hardcoded regex patterns for
patching TypeScript's internals, and these patterns in version 2.1.6
don't match the structure in TypeScript 5.8.3.
The current implementation causes duplicate `Content-Type` headers when users
override headers in the UI or use OAuth2 authentication with the agent.
Web servers receive multiple `Content-Type` headers which causes
undefined behavior and 400 errors for backends that don't accept duplicate headers.
This also fixes inconsistent behavior when overriding the `Content-Type` header
with custom values (e.g., `application/json;v=2`).
While HTTP/1.1 headers are case-insensitive per RFC 7230, inconsistent handling
across server implementations can treat differently-cased variations (e.g.,
"Content-Type" vs "content-type") as distinct headers. HTTP/2 (RFC 7540) mandates
converting all header field names to lowercase, which would prevent this issue.
This patch removes the automatic content-type header insertion, allowing user-defined
headers to take precedence without duplication. The is a temporary
workaround until we implement a HTTP/2-compliant solution with proper normalization.
This was implemented initially to support moving lower level handling
towards the kernel, although since the larger refactor has been slightly
deferred in favor of stability, this change is suitable for current
state.
This will be revisited when we implement HTTP/2 compliant header handling in the
kernel layer as part of our upcoming kernel efforts.
Use the following request to test this out on Desktop app and Agent and
override `Content-Type` header to `application/json;=v2`:
```
curl --request POST \
--url 'https://echo.qubit.codes/?qp=1' \
--header 'Content-Type: application/json;v=2' \
--data '{ "test-key": "test-value" }'
```
