starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-26 17:26:03 +03:00

[GH-ISSUE #5133] [bug]: response.meta.size.body is always 0 (response size is lower then expected) #1956

New issue

Closed

opened 2026-03-16 22:36:46 +03:00 by kerem · 11 comments

kerem commented

2026-03-16 22:36:46 +03:00

Owner

Originally created by @jessedubbink on GitHub (Jun 6, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5133

Originally assigned to: @soumyamakkar on GitHub.

Is there an existing issue for this?

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

Current behavior

When I perform a request, I get a response but I noticed that the size is too low to be correct.
After debugging I noticed that the value of response.meta.size.body is always 0. But response.meta.size.headers does have value.

I expect response.meta.size.body to contain value, and the property .total to be the sum of .body and .headers properties.
Resulting in the correct display of the response size, in the result pane.

Steps to reproduce

Create a new tab
Perform the default request (GET: https://echo.hoppscotch.io)
200 OK response but size is 62 B.
(If I calculated it correctly the response body should be 1,715 bytes + 62 bytes from the response header.)

Logs and Screenshots

response.meta.size object in chrome devtools debugger

Environment

Production

Hoppscotch Version

Cloud

Interceptor

Not Applicable - Issue not related to network requests

Browsers Affected

Chrome

Operating System

Windows

Additional Information

Also fails in an incognito tab in browser

Originally created by @jessedubbink on GitHub (Jun 6, 2025). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5133 Originally assigned to: @soumyamakkar 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 When I perform a request, I get a response but I noticed that the size is too low to be correct. After debugging I noticed that the value of response.meta.size.body is always 0. But response.meta.size.headers does have value. I expect response.meta.size.body to contain value, and the property .total to be the sum of .body and .headers properties. Resulting in the correct display of the response size, in the result pane. ### Steps to reproduce 1. Create a new tab 2. Perform the default request (GET: https://echo.hoppscotch.io) 3. 200 OK response but size is 62 B. (If I calculated it correctly the response body should be 1,715 bytes + 62 bytes from the response header.) ### Logs and Screenshots response.meta.size object in chrome devtools debugger ![Image](https://github.com/user-attachments/assets/b67df914-b562-4eb3-ade9-787006f28a0a) ![Image](https://github.com/user-attachments/assets/2aeade11-5207-41dc-94be-90848aa7b884) ### Environment Production ### Hoppscotch Version Cloud ### Interceptor Not Applicable - Issue not related to network requests ### Browsers Affected Chrome ### Operating System Windows ### Additional Information - Also fails in an incognito tab in browser

kerem

2026-03-16 22:36:46 +03:00

closed this issue
added the
bug

need testing
labels

kerem commented

2026-03-16 22:37:04 +03:00

Author

Owner

@soumyamakkar commented on GitHub (Jun 10, 2025):

Hey, can I be assigned this issue

@soumyamakkar commented on GitHub (Jun 10, 2025): Hey, can I be assigned this issue

kerem commented

2026-03-16 22:37:09 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Jun 11, 2025):

Have assigned this to you @soumyamakkar - thanks for taking this on! 🚀 Feel free to reach out if you have any questions.

Just a heads up - each interceptor has its own way of calculating meta since the underlying networking stack differs between them. You'll notice that not all interceptors are miscalculating the sizes (for example, Native on the Desktop App and Agent on the Web App calculate it correctly).

I'd recommend starting by narrowing down interceptors that are experiencing this problem. Once you know that, you can dig into the specific interceptor code in /packages/hoppscotch-common/src/platform/std/kernel-interceptors/ and look for how bodySize is calculated, then work your way up through the abstractions.

@CuriousCorrelation commented on GitHub (Jun 11, 2025): Have assigned this to you @soumyamakkar - thanks for taking this on! 🚀 Feel free to reach out if you have any questions. Just a heads up - each interceptor has its own way of calculating `meta` since the underlying networking stack differs between them. You'll notice that not all interceptors are miscalculating the sizes (for example, `Native` on the Desktop App and `Agent` on the Web App calculate it correctly). I'd recommend starting by narrowing down interceptors that are experiencing this problem. Once you know that, you can dig into the specific interceptor code in `/packages/hoppscotch-common/src/platform/std/kernel-interceptors/` and look for how `bodySize` is calculated, then work your way up through the abstractions.

kerem commented

2026-03-16 22:37:14 +03:00

Author

Owner

@g3Bg2 commented on GitHub (Jun 11, 2025):

Exactly.

@soumyamakkar

The issue is that the web interceptor is likely using .length instead of .byteLength for ArrayBuffer responses, causing them to return 0 instead of the actual byte size.

@g3Bg2 commented on GitHub (Jun 11, 2025): Exactly. @soumyamakkar The issue is that the web interceptor is likely using .length instead of .byteLength for ArrayBuffer responses, causing them to return 0 instead of the actual byte size.

kerem commented

2026-03-16 22:37:19 +03:00

Author

Owner

@soumyamakkar commented on GitHub (Jun 11, 2025):

yep, I have fixed the issue for browser. looking for other interceptors that have this issue.

@soumyamakkar commented on GitHub (Jun 11, 2025): yep, I have fixed the issue for browser. looking for other interceptors that have this issue.

kerem commented

2026-03-16 22:37:24 +03:00

Author

Owner

@soumyamakkar commented on GitHub (Jun 11, 2025):

i hope this was the expected response. lmk if I misunderstood or just a heads up if it's correct.

@soumyamakkar commented on GitHub (Jun 11, 2025): <img width="959" alt="Image" src="https://github.com/user-attachments/assets/e1069ba1-2250-498b-a5e7-e56eb9ebe0b4" /> i hope this was the expected response. lmk if I misunderstood or just a heads up if it's correct.

kerem commented

2026-03-16 22:37:29 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Jun 11, 2025):

@soumyamakkar Total size of a simple echo response going beyond 5KB (shows 16.85KB) in your screenshot seems a bit excessive.

A good way to make sure the calculations are correct would be by using this simple curl command:

curl -w "%{size_header} %{size_download}\n" \
    -o /dev/null -s https://echo.hoppscotch.io/ \
    | awk '{print ($1+$2) " bytes"}'

You can read more about it in the docs here: linux/man-pages/curl

Essentially the following from the docs:

size_download
The total amount of bytes that were downloaded. This
is the size of the body/data that was transferred,
excluding headers.

and

size_header
The total amount of bytes of the downloaded headers.

so their addition would show you the total / expected response size.

This is what I see on my machine:

> curl -w "%{size_header} %{size_download}\n" \
    -o /dev/null -s https://echo.hoppscotch.io/ \
    | awk '{print ($1+$2) " bytes"}'

> 1608 bytes

That looks correct and corresponds with Native interceptor's calculation ( +/- 100 bytes ) which is expected.

@CuriousCorrelation commented on GitHub (Jun 11, 2025): @soumyamakkar Total size of a simple echo response going beyond 5KB (shows 16.85KB) in your screenshot seems a bit excessive. A good way to make sure the calculations are correct would be by using this simple `curl` command: ``` curl -w "%{size_header} %{size_download}\n" \ -o /dev/null -s https://echo.hoppscotch.io/ \ | awk '{print ($1+$2) " bytes"}' ``` You can read more about it in the docs here: [linux/man-pages/curl](https://www.man7.org/linux/man-pages/man1/curl.1.html) Essentially the following from the docs: > **size_download** > The total amount of bytes that were downloaded. This > is the size of the body/data that was transferred, > **excluding headers**. and > **size_header** > The total amount of bytes of the **downloaded headers**. so their addition would show you the total / expected response size. This is what I see on my machine: ``` > curl -w "%{size_header} %{size_download}\n" \ -o /dev/null -s https://echo.hoppscotch.io/ \ | awk '{print ($1+$2) " bytes"}' > 1608 bytes ``` That looks correct and corresponds with `Native` interceptor's calculation ( +/- 100 bytes ) which is expected.

kerem commented

2026-03-16 22:37:34 +03:00

Author

Owner

@soumyamakkar commented on GitHub (Jun 11, 2025):

yep, you were right... think it is working fine now...

@soumyamakkar commented on GitHub (Jun 11, 2025): yep, you were right... think it is working fine now... <img width="959" alt="Image" src="https://github.com/user-attachments/assets/3ab08a2a-8427-434b-82a3-a7d9bb36437d" />

kerem commented

2026-03-16 22:37:39 +03:00

Author

Owner

@soumyamakkar commented on GitHub (Jun 11, 2025):

so @CuriousCorrelation said that it works fine on agent and native, and I checked it works fine on extension, and I fixed it on browser as well

@soumyamakkar commented on GitHub (Jun 11, 2025): so @CuriousCorrelation said that it works fine on agent and native, and I checked it works fine on extension, and I fixed it on browser as well

kerem commented

2026-03-16 22:37:45 +03:00

Author

Owner

@soumyamakkar commented on GitHub (Jun 13, 2025):

I have fixed the logic in relay implementation, but this type error is blocking my commits, which is weird because I didn't make any modifications here, maybe it is because of some recent branches that got merged: packages/hoppscotch-common do-typecheck: src/services/persistence/validation-schemas/index.ts:579:39 - error TS2345: Argument of type 'ZodObject<{ name: ZodString; status: ZodString; code: ZodCatch<ZodNullable<ZodOptional<ZodUnion<[ZodLiteral, ZodLiteral, ...ZodLiteral[]]>>>>; headers: ZodArray<...>; body: ZodString; } & { ...; }, "strip", ZodTypeAny, { ...; }, { ...; }>' is not assignable to parameter of type 'VersionedEntity<any, any>'.
packages/hoppscotch-common do-typecheck: Type 'ZodObject<{ name: ZodString; status: ZodString; code: ZodCatch<ZodNullable<ZodOptional<ZodUnion<[ZodLiteral, ZodLiteral, ...ZodLiteral[]]>>>>; headers: ZodArray<...>; body: ZodString; } & { ...; }, "strip", ZodTypeAny, { ...; }, { ...; }>' is missing the following properties from type 'VersionedEntity<any, any>': versionMap, latestVersion, getVersion, is, and 3 more.
packages/hoppscotch-common do-typecheck: 579 response: entityReference(HoppRESTRequestResponse),
packages/hoppscotch-common do-typecheck: ~~~~~~~~~~~~~~~~~~~~~~~
packages/hoppscotch-common do-typecheck: Failed
C:\Users\Vansh\Desktop\DESKTOP\hoppscotch\packages\hoppscotch-common:
ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL @hoppscotch/common@2025.5.2 do-typecheck: node type-check.mjs
Exit status 1

@soumyamakkar commented on GitHub (Jun 13, 2025): I have fixed the logic in relay implementation, but this type error is blocking my commits, which is weird because I didn't make any modifications here, maybe it is because of some recent branches that got merged: packages/hoppscotch-common do-typecheck: src/services/persistence/validation-schemas/index.ts:579:39 - error TS2345: Argument of type 'ZodObject<{ name: ZodString; status: ZodString; code: ZodCatch<ZodNullable<ZodOptional<ZodUnion<[ZodLiteral<number>, ZodLiteral<number>, ...ZodLiteral<number>[]]>>>>; headers: ZodArray<...>; body: ZodString; } & { ...; }, "strip", ZodTypeAny, { ...; }, { ...; }>' is not assignable to parameter of type 'VersionedEntity<any, any>'. packages/hoppscotch-common do-typecheck: Type 'ZodObject<{ name: ZodString; status: ZodString; code: ZodCatch<ZodNullable<ZodOptional<ZodUnion<[ZodLiteral<number>, ZodLiteral<number>, ...ZodLiteral<number>[]]>>>>; headers: ZodArray<...>; body: ZodString; } & { ...; }, "strip", ZodTypeAny, { ...; }, { ...; }>' is missing the following properties from type 'VersionedEntity<any, any>': versionMap, latestVersion, getVersion, is, and 3 more. packages/hoppscotch-common do-typecheck: 579 response: entityReference(HoppRESTRequestResponse), packages/hoppscotch-common do-typecheck: ~~~~~~~~~~~~~~~~~~~~~~~ packages/hoppscotch-common do-typecheck: Failed C:\Users\Vansh\Desktop\DESKTOP\hoppscotch\packages\hoppscotch-common: ERR_PNPM_RECURSIVE_RUN_FIRST_FAIL @hoppscotch/common@2025.5.2 do-typecheck: `node type-check.mjs` Exit status 1

kerem commented

2026-03-16 22:37:50 +03:00

Author

Owner

@CuriousCorrelation commented on GitHub (Jun 16, 2025):

@soumyamakkar In response to your comment, I've posted info about the TypeScript error in the PR's comment

Let's keep further discussions about the PR in the PR's comment section to help with tracking. Thanks!

@CuriousCorrelation commented on GitHub (Jun 16, 2025): @soumyamakkar In response to your comment, I've posted info about the TypeScript error in the [PR's comment](https://github.com/hoppscotch/hoppscotch/pull/5141#issuecomment-2975398377) Let's keep further discussions about the PR in the PR's comment section to help with tracking. Thanks!

kerem commented

2026-03-16 22:37:55 +03:00

Author

Owner

@jessedubbink commented on GitHub (Jun 20, 2025):

Fantastic!

@jessedubbink commented on GitHub (Jun 20, 2025): Fantastic! ![Image](https://github.com/user-attachments/assets/a1374ac4-6001-4153-aaf2-d763fe5b4efb)