starred/Proxyman

Fork 0

mirror of https://github.com/ProxymanApp/Proxyman.git synced 2026-04-27 17:15:49 +03:00

[GH-ISSUE #1699] [Scripting] The `response.rawBody` property does not preserve the original request body payload #1691

New issue

Open

opened 2026-03-03 19:53:31 +03:00 by kerem · 3 comments

kerem commented

2026-03-03 19:53:31 +03:00

Owner

Originally created by @hkosacki on GitHub (Jun 30, 2023).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/1699

Description

I just spotted an issue when I needed to amend the response with a dynamically modified property and calculated signature on the client side (Proxyman). As a result, it has turned out that the response.rawBody property does not guarantee its contents to be exactly the same as the body response payload, which resulted in being unable to calculate the proper signature (the raw response body was different in the script and in the client app).

Steps to Reproduce

Add the following snippet for scripting for any of the endpoints:

async function onResponse(context, url, request, response) {
  console.log("\n" + response.rawBody);
  return response;
}

Perform any request that runs the script.
Observe the logs, compare the request body and the console logs.

Current Behavior

The logged body contents differ from the ones in the response body.

Expected Behavior

The logged body contents should be the same as the ones in the response body in the Proxyman window.

Environment

App version: e.g Proxyman 4.8.1
macOS version: e.g macOS Ventura 13.4.1 (22F82)

Please tell me if you need more support by reproducing the issue, or if I can help in some other way.

Cheers!

Originally created by @hkosacki on GitHub (Jun 30, 2023). Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/1699 ## Description I just spotted an issue when I needed to amend the response with a dynamically modified property and calculated signature on the client side (Proxyman). As a result, it has turned out that the `response.rawBody` property does not guarantee its contents to be exactly the same as the body response payload, which resulted in being unable to calculate the proper signature (the raw response body was different in the script and in the client app). ## Steps to Reproduce 1. Add the following snippet for scripting for any of the endpoints: ``` async function onResponse(context, url, request, response) { console.log("\n" + response.rawBody); return response; } ``` 2. Perform any request that runs the script. 3. Observe the logs, compare the request body and the console logs. ## Current Behavior The logged body contents differ from the ones in the response body. ## Expected Behavior The logged body contents should be the same as the ones in the response body in the Proxyman window. ## Environment - App version: e.g Proxyman 4.8.1 - macOS version: e.g macOS Ventura 13.4.1 (22F82) Please tell me if you need more support by reproducing the issue, or if I can help in some other way. Cheers!

kerem added the

bug

label

2026-03-03 19:53:31 +03:00

kerem commented

2026-03-03 19:53:32 +03:00

Author

Owner

@hkosacki commented on GitHub (Jun 30, 2023):

Please find the screenshot attached:

@hkosacki commented on GitHub (Jun 30, 2023): Please find the screenshot attached: ![image](https://github.com/ProxymanApp/Proxyman/assets/7702378/c4b2d2e1-3abf-4b93-8376-e65341bdf92d)

kerem commented

2026-03-03 19:53:32 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jun 30, 2023):

I'd say that it's the expected behavior of the Scripting.

Proxyman passes the Dictionary (Body) to the Script (JavascriptCore), and converts the Dictionary back to the Swift. By default, Dictionary doesn't respect the key order, so the issue happens.

@hkosacki the key order is different, but the Dictionary is the same.

@NghiaTranUIT commented on GitHub (Jun 30, 2023): I'd say that it's the expected behavior of the Scripting. Proxyman passes the Dictionary (Body) to the Script (JavascriptCore), and converts the Dictionary back to the Swift. By default, Dictionary doesn't respect the key order, so the issue happens. @hkosacki the key order is different, but the Dictionary is the same.

kerem commented

2026-03-03 19:53:32 +03:00

Author

Owner

@hkosacki commented on GitHub (Jul 3, 2023):

I see your point. But this kind of behaviour I find desired if we are talking about the parsed body structure under the response.body property, since there the order of the items indeed does not matter.
But then, regarding rawBody property, I'd say that its name is actually misleading if there is no way to guarantee the original payload here.

The documentation claims the following:
rawBody": "<Readonly>: A raw body String or Base64 encoded string if it's a binary",

As the user, I'd expect from the raw body String to be exactly the same as it could be seen in the response lookup view.

the key order is different, but the Dictionary is the same.

This unfortunately doesn't allow me to perform any calculation on mocked/modified responses in terms of providing its SHA1 hash etc., since I have no guarantee to receive the same payload in my client app.

@hkosacki commented on GitHub (Jul 3, 2023): I see your point. But this kind of behaviour I find desired if we are talking about the parsed body structure under the `response.body` property, since there the order of the items indeed does not matter. But then, regarding `rawBody` property, I'd say that its name is actually misleading if there is no way to guarantee the original payload here. The documentation claims the following: ```rawBody": "<Readonly>: A raw body String or Base64 encoded string if it's a binary",``` As the user, I'd expect from the `raw body String` to be exactly the same as it could be seen in the response lookup view. > the key order is different, but the Dictionary is the same. This unfortunately doesn't allow me to perform any calculation on mocked/modified responses in terms of providing its SHA1 hash etc., since I have no guarantee to receive the same payload in my client app.