fix: handle missing Content-Type when importing curl POST
When importing a curl POST request with a body and no explicit
Content-Type, default to `application/x-www-form-urlencoded`
to match curl's behavior.
Reference: https://everything.curl.dev/http/post/content-type.html
This PR adds a file-based logging system with size-based rotation to the desktop application. It essentially redirects existing diagnostic to size-based rotating files for troubleshooting environment-specific issues.
Closes HFE-801
The desktop application currently lacks a persistent logging mechanism in production environments. Logs are only available through the development mode console.
This PR will help diagnose issues reported in #4859, #4950, #5003, discussions #4984 and #4986.
Mainly aiming to understand errors in specific environments that can't be reproduced in our testing setups.
This implementation uses the tracing ecosystem (`tracing`, `tracing_subscriber`, `tracing_appender`) along with `file_rotate` to create log files in the platform's log directory. The logs are automatically rotated when they reach `10MB`, with a maximum of `5` files retained.
Thinking 10 * 5 MB is reasonable disk usage while maintaining sufficient history.
The system currently writes to both the console (with ANSI colors where supported) and to files (without ANSI formatting for readability). Log levels are currently controlled via the `RUST_LOG` environment variable, defaulting to "debug" when not specified.
| OS | Log File Path |
|---------|------------------------------------------------------|
| Windows | `C:\Users\<username>\AppData\Local\io.hoppscotch.desktop\logs\io.hoppscotch.desktop.log` |
| macOS | `~/Library/Logs/io.hoppscotch.desktop/io.hoppscotch.desktop.log` |
| Linux | `~/.local/share/io.hoppscotch.desktop/logs/io.hoppscotch.desktop.log` |
This fix replace `sys-info v0.9.1` with
the more actively maintained `sysinfo 0.34.2`
which does return size of the disk in bytes.
Closes#5017, HFE-831
Rebased on #5010, consider merging that first.
Issues:
Appload fails to load with a "Storage full" error despite
having sufficient disk space.
This was caused by a unit mismatch in the `sys-info` crate
which returns disk space in kilobytes instead of bytes.
- sys_info::disk_info() returns values in KB, see:
60ecf1470a/c/linux.c (L119)
- The `StorageFull` error was triggered when comparing
raw bytes against a KB value, causing false positive
Changes:
- Rewrite the `ensure_space` function to find the correct disk of the config dir
- Add a new `StorageError::DiskNotFound` for cases where the disk cannot
be resolved
fix: add win version checks for DWM attr api
This adds version checking before using Windows 11-specific DWM APIs.
Closes HFE-821
The desktop app crashes on startup on older Windows versions (pre-Windows 11)
due to unsupported DWM API calls for dark mode and caption styling.
According to docs at https://learn.microsoft.com/en-us/windows/win32/api/dwmapi/ne-dwmapi-dwmwindowattribute,
both `DWMWA_USE_IMMERSIVE_DARK_MODE` and `DWMWA_CAPTION_COLOR` attributes
are only supported starting with Windows 11 Build 22000.
> DWMWA_USE_IMMERSIVE_DARK_MODE: [...] This value is supported starting
> with Windows 11 Build 22000"
and
> DWMWA_CAPTION_COLOR: [...] This value is supported starting
> with Windows 11 Build 22000.
See https://github.com/hoppscotch/hoppscotch/discussions/4984 for more details,
for reports of app crashing immediately on startup with these errors:
```
Failed to set dark mode: Error { code: HRESULT(0x80070057), message: "The parameter is incorrect." }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[0417/150158.530:ERROR:window_impl.cc(122)] Failed to unregister class Chrome_WidgetWin_0. Error = 1412
```
The tests were all over the place, both attributes (sometimes!) seems to be present
on Windows 10 1809 and even earlier, only if it was installed with network access,
so perhaps this is due to Windows updates? Other times, they weren't, especially on VMs.
The issue is reproducible on Windows Server 2019 Datacenter (v10.0.17763),
which is equivalent to Windows 10 version 1809.
This version is too old to support DWMWA_USE_IMMERSIVE_DARK_MODE,
which is only **officially supported** starting with Windows 11 Build 22000
according to Microsoft's documentation.
So at the moment, relying on official docs seems to be the right call,
and themes are definitely something app shouldn't crash for regardless.
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.
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.
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" }'
```
