[PR #4945] [MERGED] fix(kernel): deterministic form data processing #4997

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

📋 Pull Request Information

Original PR: https://github.com/hoppscotch/hoppscotch/pull/4945
Author: @CuriousCorrelation
Created: 3/28/2025
Status: Merged
Merged: 4/8/2025
Merged by: @jamesgeorge007

Base: patchHead: fix-kernel-request-process-serde


📝 Commits (3)

  • bd7eab5 fix(kernel): deterministic form data processing
  • fd7f1b3 fix: remove debug logs
  • 6908690 perf(web): intermediate map for poll optimization

📊 Changes

19 files changed (+219 additions, -189 deletions)

View changed files

📝 packages/hoppscotch-agent/src-tauri/Cargo.lock (+1 -2)
📝 packages/hoppscotch-common/src/helpers/functional/process-request.ts (+6 -0)
📝 packages/hoppscotch-common/src/platform/std/kernel-interceptors/agent/index.ts (+10 -2)
📝 packages/hoppscotch-common/src/platform/std/kernel-interceptors/agent/store.ts (+1 -4)
📝 packages/hoppscotch-common/src/platform/std/kernel-interceptors/browser/index.ts (+1 -1)
📝 packages/hoppscotch-common/src/platform/std/kernel-interceptors/extension/index.ts (+1 -1)
📝 packages/hoppscotch-common/src/platform/std/kernel-interceptors/native/index.ts (+146 -112)
📝 packages/hoppscotch-common/src/platform/std/kernel-interceptors/proxy/index.ts (+1 -1)
📝 packages/hoppscotch-desktop/plugin-workspace/relay/Cargo.lock (+1 -25)
📝 packages/hoppscotch-desktop/plugin-workspace/relay/Cargo.toml (+0 -1)
📝 packages/hoppscotch-desktop/plugin-workspace/relay/src/content.rs (+2 -3)
📝 packages/hoppscotch-desktop/plugin-workspace/relay/src/interop.rs (+1 -2)
📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-relay/Cargo.lock (+1 -2)
📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-relay/dist-js/index.d.ts (+1 -1)
📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-relay/dist-js/index.d.ts.map (+1 -1)
📝 packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-relay/guest-js/index.ts (+1 -1)
📝 packages/hoppscotch-desktop/src-tauri/Cargo.lock (+2 -3)
📝 packages/hoppscotch-kernel/src/relay/v/1.ts (+38 -23)
📝 pnpm-lock.yaml (+4 -4)

📄 Description

When submitting form data requests, the form fields were being processed in a non-deterministic order due to the use of JavaScript's Map structure for serialization. While this was partially addressed in https://github.com/hoppscotch/hoppscotch/pull/4892, the necessity of map -> obj flattening as explained in the PR code caused yet another unpredictable ordering.

The reason being "The mechanics and order of enumerating the properties ... is not specified." in the ECMAScript spec http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf. So while inconsistent request payloads between different runs was fixed, now the order was unintentionally deterministic/sorted, particularly affecting multipart/form-data requests where field order would change.

This was happening due to all numeric keys being sorted to the top and string keys after that, which is the default behavior for JavaScript objects. For example, if you had form fields with keys like "name", "email", "1", "2", "phone", the JavaScript object would enumerate them as "1", "2", "name", "email", "phone" - sorting all numeric keys first in ascending order, followed by string keys in insertion order. This behavior is problematic for multipart form data where the server might expect fields in a specific order or where the order of fields needs to be preserved exactly as they were entered, see https://github.com/hoppscotch/hoppscotch/issues/4889.

Closes HFE-797

The core issue was the use of IndexMap in Rust and Map in JavaScript, which while guaranteeing consistent iteration order when serialized across platforms, the inconsistency manifested by Javascript's obj ordering sent different orders at the receiving server's end.

This PR implements a deterministic approach to form data processing by replacing map-based structures with array-based representations similar to what superjson does. Added a postProcessRelayRequest with superjson.serialize to make sure we have consistent serialization between agent and native interceptors. Also updated form data processing in the kernel interceptors to use this deterministic structure, and removed the dependency on indexmap in the Rust side. The makeFormDataSerializable function has been refactored to build arrays directly instead of converting maps.

Form data now maintains consistent field ordering between requests.

Notes to reviewers

You can verify this fix by running the following curl command and comparing it with echo.hoppscotch.io's base64 response:

curl --request POST \
  --url https://echo.hoppscotch.io/ \
  --header 'content-type: multipart/form-data' \
  --form key=1 \
  --form another_key=2 \
  --form yet_another_key=3 \
  --form one_more_key=4 \
  --form 111=5 \
  --form 11=6 \
  --form 1=7 \
  --form 0=8

Note that copy-pasting this directly will insert it in different order, this is an unrelated issue and can be tackled later, for now reinserting form-data or manually reordering them is a good workaround.

RFC 7578 section 5.2 explicitly states: "Form processors given forms with a well-defined ordering SHOULD send back results in order. Intermediaries MUST NOT reorder the results." but some servers don't follow this explicitly so you may notice non-deterministic ordering. The best way would be to decode the base64 response from echo.hoppscotch.io since we do maintain the order.

Test Results

Before After
before after

Before

LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1ncUR4VFJMT2FWa0JoMkVKMXRSbXU2DQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9IjAiDQoNCjgNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tZ3FEeFRSTE9hVmtCaDJFSjF0Um11Ng0KQ29udGVudC1EaXNwb3NpdGlvbjogZm9ybS1kYXRhOyBuYW1lPSIxIg0KDQo3DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLWdxRHhUUkxPYVZrQmgyRUoxdFJtdTYNCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0iMTEiDQoNCjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tZ3FEeFRSTE9hVmtCaDJFSjF0Um11Ng0KQ29udGVudC1EaXNwb3NpdGlvbjogZm9ybS1kYXRhOyBuYW1lPSIxMTEiDQoNCjUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tZ3FEeFRSTE9hVmtCaDJFSjF0Um11Ng0KQ29udGVudC1EaXNwb3NpdGlvbjogZm9ybS1kYXRhOyBuYW1lPSJhbm90aGVyX2tleSINCg0KMg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1ncUR4VFJMT2FWa0JoMkVKMXRSbXU2DQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9ImtleSINCg0KMQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1ncUR4VFJMT2FWa0JoMkVKMXRSbXU2DQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9Im9uZV9tb3JlX2tleSINCg0KNA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1ncUR4VFJMT2FWa0JoMkVKMXRSbXU2DQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9InlldF9hbm90aGVyX2tleSINCg0KMw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1ncUR4VFJMT2FWa0JoMkVKMXRSbXU2LS0NCg==

Decoded To

--------------------------gqDxTRLOaVkBh2EJ1tRmu6
Content-Disposition: form-data; name="0"

8
--------------------------gqDxTRLOaVkBh2EJ1tRmu6
Content-Disposition: form-data; name="1"

7
--------------------------gqDxTRLOaVkBh2EJ1tRmu6
Content-Disposition: form-data; name="11"

6
--------------------------gqDxTRLOaVkBh2EJ1tRmu6
Content-Disposition: form-data; name="111"

5
--------------------------gqDxTRLOaVkBh2EJ1tRmu6
Content-Disposition: form-data; name="another_key"

2
--------------------------gqDxTRLOaVkBh2EJ1tRmu6
Content-Disposition: form-data; name="key"

1
--------------------------gqDxTRLOaVkBh2EJ1tRmu6
Content-Disposition: form-data; name="one_more_key"

4
--------------------------gqDxTRLOaVkBh2EJ1tRmu6
Content-Disposition: form-data; name="yet_another_key"

3
--------------------------gqDxTRLOaVkBh2EJ1tRmu6--

After

LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1KRE9WYmc3QU5FYm9UazF5SHg4Vk1SDQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9ImtleSINCg0KMQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1KRE9WYmc3QU5FYm9UazF5SHg4Vk1SDQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9ImFub3RoZXJfa2V5Ig0KDQoyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUpET1ZiZzdBTkVib1RrMXlIeDhWTVINCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0ieWV0X2Fub3RoZXJfa2V5Ig0KDQozDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUpET1ZiZzdBTkVib1RrMXlIeDhWTVINCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0ib25lX21vcmVfa2V5Ig0KDQo0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUpET1ZiZzdBTkVib1RrMXlIeDhWTVINCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0iMTExIg0KDQo1DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUpET1ZiZzdBTkVib1RrMXlIeDhWTVINCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0iMTEiDQoNCjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tSkRPVmJnN0FORWJvVGsxeUh4OFZNUg0KQ29udGVudC1EaXNwb3NpdGlvbjogZm9ybS1kYXRhOyBuYW1lPSIxIg0KDQo3DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUpET1ZiZzdBTkVib1RrMXlIeDhWTVINCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0iMCINCg0KOA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1KRE9WYmc3QU5FYm9UazF5SHg4Vk1SLS0NCg==

Decoded To

--------------------------JDOVbg7ANEboTk1yHx8VMR
Content-Disposition: form-data; name="key"

1
--------------------------JDOVbg7ANEboTk1yHx8VMR
Content-Disposition: form-data; name="another_key"

2
--------------------------JDOVbg7ANEboTk1yHx8VMR
Content-Disposition: form-data; name="yet_another_key"

3
--------------------------JDOVbg7ANEboTk1yHx8VMR
Content-Disposition: form-data; name="one_more_key"

4
--------------------------JDOVbg7ANEboTk1yHx8VMR
Content-Disposition: form-data; name="111"

5
--------------------------JDOVbg7ANEboTk1yHx8VMR
Content-Disposition: form-data; name="11"

6
--------------------------JDOVbg7ANEboTk1yHx8VMR
Content-Disposition: form-data; name="1"

7
--------------------------JDOVbg7ANEboTk1yHx8VMR
Content-Disposition: form-data; name="0"

8
--------------------------JDOVbg7ANEboTk1yHx8VMR--


🔄 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/4945 **Author:** [@CuriousCorrelation](https://github.com/CuriousCorrelation) **Created:** 3/28/2025 **Status:** ✅ Merged **Merged:** 4/8/2025 **Merged by:** [@jamesgeorge007](https://github.com/jamesgeorge007) **Base:** `patch` ← **Head:** `fix-kernel-request-process-serde` --- ### 📝 Commits (3) - [`bd7eab5`](https://github.com/hoppscotch/hoppscotch/commit/bd7eab5ee610d453cbfa5c3ae40bea943ead01fa) fix(kernel): deterministic form data processing - [`fd7f1b3`](https://github.com/hoppscotch/hoppscotch/commit/fd7f1b341175cd76b6feeebfafece408818a297c) fix: remove debug logs - [`6908690`](https://github.com/hoppscotch/hoppscotch/commit/690869014721d222acd14835788f51335e05056c) perf(web): intermediate map for poll optimization ### 📊 Changes **19 files changed** (+219 additions, -189 deletions) <details> <summary>View changed files</summary> 📝 `packages/hoppscotch-agent/src-tauri/Cargo.lock` (+1 -2) 📝 `packages/hoppscotch-common/src/helpers/functional/process-request.ts` (+6 -0) 📝 `packages/hoppscotch-common/src/platform/std/kernel-interceptors/agent/index.ts` (+10 -2) 📝 `packages/hoppscotch-common/src/platform/std/kernel-interceptors/agent/store.ts` (+1 -4) 📝 `packages/hoppscotch-common/src/platform/std/kernel-interceptors/browser/index.ts` (+1 -1) 📝 `packages/hoppscotch-common/src/platform/std/kernel-interceptors/extension/index.ts` (+1 -1) 📝 `packages/hoppscotch-common/src/platform/std/kernel-interceptors/native/index.ts` (+146 -112) 📝 `packages/hoppscotch-common/src/platform/std/kernel-interceptors/proxy/index.ts` (+1 -1) 📝 `packages/hoppscotch-desktop/plugin-workspace/relay/Cargo.lock` (+1 -25) 📝 `packages/hoppscotch-desktop/plugin-workspace/relay/Cargo.toml` (+0 -1) 📝 `packages/hoppscotch-desktop/plugin-workspace/relay/src/content.rs` (+2 -3) 📝 `packages/hoppscotch-desktop/plugin-workspace/relay/src/interop.rs` (+1 -2) 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-relay/Cargo.lock` (+1 -2) 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-relay/dist-js/index.d.ts` (+1 -1) 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-relay/dist-js/index.d.ts.map` (+1 -1) 📝 `packages/hoppscotch-desktop/plugin-workspace/tauri-plugin-relay/guest-js/index.ts` (+1 -1) 📝 `packages/hoppscotch-desktop/src-tauri/Cargo.lock` (+2 -3) 📝 `packages/hoppscotch-kernel/src/relay/v/1.ts` (+38 -23) 📝 `pnpm-lock.yaml` (+4 -4) </details> ### 📄 Description When submitting form data requests, the form fields were being processed in a non-deterministic order due to the use of JavaScript's `Map` structure for serialization. While this was partially addressed in https://github.com/hoppscotch/hoppscotch/pull/4892, the necessity of `map -> obj` flattening as explained in the PR code caused yet another unpredictable ordering. The reason being "The mechanics and order of enumerating the properties ... is not specified." in the ECMAScript spec http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-262.pdf. So while inconsistent request payloads between different runs was fixed, now the order was unintentionally deterministic/sorted, particularly affecting `multipart/form-data` requests where field order would change. This was happening due to all numeric keys being sorted to the top and string keys after that, which is the default behavior for JavaScript objects. For example, if you had form fields with keys like "name", "email", "1", "2", "phone", the JavaScript object would enumerate them as "1", "2", "name", "email", "phone" - sorting all numeric keys first in ascending order, followed by string keys in insertion order. This behavior is problematic for multipart form data where the server might expect fields in a specific order or where the order of fields needs to be preserved exactly as they were entered, see https://github.com/hoppscotch/hoppscotch/issues/4889. Closes HFE-797 The core issue was the use of `IndexMap` in Rust and `Map` in JavaScript, which while guaranteeing consistent iteration order when serialized across platforms, the inconsistency manifested by Javascript's obj ordering sent different orders at the receiving server's end. This PR implements a deterministic approach to form data processing by replacing map-based structures with array-based representations similar to what `superjson` does. Added a `postProcessRelayRequest` with `superjson.serialize` to make sure we have consistent serialization between `agent` and `native` interceptors. Also updated form data processing in the kernel interceptors to use this deterministic structure, and removed the dependency on `indexmap` in the Rust side. The `makeFormDataSerializable` function has been refactored to build arrays directly instead of converting maps. Form data now maintains consistent field ordering between requests. ### Notes to reviewers You can verify this fix by running the following curl command and comparing it with `echo.hoppscotch.io`'s base64 response: ``` curl --request POST \ --url https://echo.hoppscotch.io/ \ --header 'content-type: multipart/form-data' \ --form key=1 \ --form another_key=2 \ --form yet_another_key=3 \ --form one_more_key=4 \ --form 111=5 \ --form 11=6 \ --form 1=7 \ --form 0=8 ``` Note that copy-pasting this directly will insert it in different order, this is an unrelated issue and can be tackled later, for now reinserting form-data or manually reordering them is a good workaround. [RFC 7578 section 5.2](https://datatracker.ietf.org/doc/html/rfc7578#section-5.2) explicitly states: "Form processors given forms with a well-defined ordering SHOULD send back results in order. Intermediaries MUST NOT reorder the results." but some servers don't follow this explicitly so you may notice non-deterministic ordering. The best way would be to decode the base64 response from `echo.hoppscotch.io` since we do maintain the order. ### Test Results | Before | After | | ------ | ------ | | ![before](https://github.com/user-attachments/assets/36092542-1941-41c1-9989-1325e72595a8) | ![after](https://github.com/user-attachments/assets/e51bfe9b-edc6-41ad-9fab-683a33e00c9d) | #### Before ``` LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1ncUR4VFJMT2FWa0JoMkVKMXRSbXU2DQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9IjAiDQoNCjgNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tZ3FEeFRSTE9hVmtCaDJFSjF0Um11Ng0KQ29udGVudC1EaXNwb3NpdGlvbjogZm9ybS1kYXRhOyBuYW1lPSIxIg0KDQo3DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLWdxRHhUUkxPYVZrQmgyRUoxdFJtdTYNCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0iMTEiDQoNCjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tZ3FEeFRSTE9hVmtCaDJFSjF0Um11Ng0KQ29udGVudC1EaXNwb3NpdGlvbjogZm9ybS1kYXRhOyBuYW1lPSIxMTEiDQoNCjUNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tZ3FEeFRSTE9hVmtCaDJFSjF0Um11Ng0KQ29udGVudC1EaXNwb3NpdGlvbjogZm9ybS1kYXRhOyBuYW1lPSJhbm90aGVyX2tleSINCg0KMg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1ncUR4VFJMT2FWa0JoMkVKMXRSbXU2DQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9ImtleSINCg0KMQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1ncUR4VFJMT2FWa0JoMkVKMXRSbXU2DQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9Im9uZV9tb3JlX2tleSINCg0KNA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1ncUR4VFJMT2FWa0JoMkVKMXRSbXU2DQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9InlldF9hbm90aGVyX2tleSINCg0KMw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1ncUR4VFJMT2FWa0JoMkVKMXRSbXU2LS0NCg== ``` #### Decoded To ``` --------------------------gqDxTRLOaVkBh2EJ1tRmu6 Content-Disposition: form-data; name="0" 8 --------------------------gqDxTRLOaVkBh2EJ1tRmu6 Content-Disposition: form-data; name="1" 7 --------------------------gqDxTRLOaVkBh2EJ1tRmu6 Content-Disposition: form-data; name="11" 6 --------------------------gqDxTRLOaVkBh2EJ1tRmu6 Content-Disposition: form-data; name="111" 5 --------------------------gqDxTRLOaVkBh2EJ1tRmu6 Content-Disposition: form-data; name="another_key" 2 --------------------------gqDxTRLOaVkBh2EJ1tRmu6 Content-Disposition: form-data; name="key" 1 --------------------------gqDxTRLOaVkBh2EJ1tRmu6 Content-Disposition: form-data; name="one_more_key" 4 --------------------------gqDxTRLOaVkBh2EJ1tRmu6 Content-Disposition: form-data; name="yet_another_key" 3 --------------------------gqDxTRLOaVkBh2EJ1tRmu6-- ``` #### After ``` LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1KRE9WYmc3QU5FYm9UazF5SHg4Vk1SDQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9ImtleSINCg0KMQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1KRE9WYmc3QU5FYm9UazF5SHg4Vk1SDQpDb250ZW50LURpc3Bvc2l0aW9uOiBmb3JtLWRhdGE7IG5hbWU9ImFub3RoZXJfa2V5Ig0KDQoyDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUpET1ZiZzdBTkVib1RrMXlIeDhWTVINCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0ieWV0X2Fub3RoZXJfa2V5Ig0KDQozDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUpET1ZiZzdBTkVib1RrMXlIeDhWTVINCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0ib25lX21vcmVfa2V5Ig0KDQo0DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUpET1ZiZzdBTkVib1RrMXlIeDhWTVINCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0iMTExIg0KDQo1DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUpET1ZiZzdBTkVib1RrMXlIeDhWTVINCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0iMTEiDQoNCjYNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tSkRPVmJnN0FORWJvVGsxeUh4OFZNUg0KQ29udGVudC1EaXNwb3NpdGlvbjogZm9ybS1kYXRhOyBuYW1lPSIxIg0KDQo3DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLUpET1ZiZzdBTkVib1RrMXlIeDhWTVINCkNvbnRlbnQtRGlzcG9zaXRpb246IGZvcm0tZGF0YTsgbmFtZT0iMCINCg0KOA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS1KRE9WYmc3QU5FYm9UazF5SHg4Vk1SLS0NCg== ``` #### Decoded To ``` --------------------------JDOVbg7ANEboTk1yHx8VMR Content-Disposition: form-data; name="key" 1 --------------------------JDOVbg7ANEboTk1yHx8VMR Content-Disposition: form-data; name="another_key" 2 --------------------------JDOVbg7ANEboTk1yHx8VMR Content-Disposition: form-data; name="yet_another_key" 3 --------------------------JDOVbg7ANEboTk1yHx8VMR Content-Disposition: form-data; name="one_more_key" 4 --------------------------JDOVbg7ANEboTk1yHx8VMR Content-Disposition: form-data; name="111" 5 --------------------------JDOVbg7ANEboTk1yHx8VMR Content-Disposition: form-data; name="11" 6 --------------------------JDOVbg7ANEboTk1yHx8VMR Content-Disposition: form-data; name="1" 7 --------------------------JDOVbg7ANEboTk1yHx8VMR Content-Disposition: form-data; name="0" 8 --------------------------JDOVbg7ANEboTk1yHx8VMR-- ``` --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
kerem 2026-03-17 02:29:12 +03:00
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#4997
No description provided.