[GH-ISSUE #1512] Scripting changes + to %2B in query string #1506

Closed
opened 2026-03-03 19:52:01 +03:00 by kerem · 12 comments
Owner

Originally created by @gabrielmaldi on GitHub (Jan 24, 2023).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/1512

Originally assigned to: @NghiaTranUIT on GitHub.

Description

When using a script like the following to rewrite the URL:

async function onRequest(context, url, request) {
  request.scheme = "http";
  request.host = "myserver";
  request.port = 1234;
  request.path = request.path.replace("/some-path/api/", "/another-path/api/");

  return request;
}

If the URL contains + chars in the query string (note the script doesn't alter request.queries), they get encoded to %2B, which may cause the request to fail on the server.

The Map Remote tool does not have this problem: I can successfully rewrite a request without other unwanted changes.

Steps to Reproduce

Create a script like the above and intercept a request which contains a + char.

The following first image shows the request being rewritten by Map Remote, and se second image shows the same request rewritten by Scripting, which causes the server to fail (the arrows point to the modified chars in the query string).

Screenshot 2023-01-24 at 20 41 28 Screenshot 2023-01-24 at 20 43 00

Current Behavior

+ chars are changed to %2B.

Expected Behavior

+ chars are preserved.

Environment

  • App version: Proxyman 4.0.0 (40000)
  • macOS version: macOS 13.1 (22C65)
Originally created by @gabrielmaldi on GitHub (Jan 24, 2023). Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/1512 Originally assigned to: @NghiaTranUIT on GitHub. ## Description When using a script like the following to rewrite the URL: ```js async function onRequest(context, url, request) { request.scheme = "http"; request.host = "myserver"; request.port = 1234; request.path = request.path.replace("/some-path/api/", "/another-path/api/"); return request; } ``` If the URL contains `+` chars in the query string (note the script doesn't alter `request.queries`), they get encoded to `%2B`, which may cause the request to fail on the server. The Map Remote tool does not have this problem: I can successfully rewrite a request without other unwanted changes. ## Steps to Reproduce Create a script like the above and intercept a request which contains a `+` char. The following first image shows the request being rewritten by Map Remote, and se second image shows the same request rewritten by Scripting, which causes the server to fail (the arrows point to the modified chars in the query string). <img width="1440" alt="Screenshot 2023-01-24 at 20 41 28" src="https://user-images.githubusercontent.com/3728897/214446423-1f776a8a-7538-483d-b735-0fea90a77a0b.png"> <img width="1440" alt="Screenshot 2023-01-24 at 20 43 00" src="https://user-images.githubusercontent.com/3728897/214446432-70b36b12-b7c1-44aa-9645-b78c8ee28fff.png"> ## Current Behavior `+` chars are changed to `%2B`. ## Expected Behavior `+` chars are preserved. ## Environment - App version: Proxyman 4.0.0 (40000) - macOS version: macOS 13.1 (22C65)
kerem 2026-03-03 19:52:01 +03:00
Author
Owner

@gabrielmaldi commented on GitHub (Jan 25, 2023):

Just discovered request.isURLEncoding = false. That somewhat helps: it solves the problem I described above for that specific request, but causes other requests to fail (since as stated will prevent encoding of the query string).

Maybe the solution is to apply these encoding rules? In my case, + should be a space char, which the server would handle correctly (and the problem is that currently Proxyman is encoding it as %2B which is the plus sign char).

Thanks!

<!-- gh-comment-id:1402869944 --> @gabrielmaldi commented on GitHub (Jan 25, 2023): Just discovered `request.isURLEncoding = false`. That somewhat helps: it solves the problem I described above for that specific request, but causes other requests to fail (since as stated will prevent encoding of the query string). Maybe the solution is to apply [these](https://stackoverflow.com/a/2678602/474031) encoding rules? In my case, `+` should be a space char, which the server would handle correctly (and the problem is that currently Proxyman is encoding it as `%2B` which is the plus sign char). Thanks!
Author
Owner

@NghiaTranUIT commented on GitHub (Jan 25, 2023):

@gabrielmaldi by default, the + will always be percented-encoded, it's the standard of the Restful APIs.

If we force to not encode the +, it might cause bug on other apps.

I guess, if you don't modify the query, I will keep reserving the original data without performing the encoding. So it fixes your problem and all people.

<!-- gh-comment-id:1402895660 --> @NghiaTranUIT commented on GitHub (Jan 25, 2023): @gabrielmaldi by default, the `+` will always be percented-encoded, it's the standard of the Restful APIs. If we force to not encode the `+`, it might cause bug on other apps. I guess, if you don't modify the query, I will keep reserving the original data without performing the encoding. So it fixes your problem and all people.
Author
Owner

@gabrielmaldi commented on GitHub (Jan 25, 2023):

if you don't modify the query, I will keep reserving the original data without performing the encoding

I agree with that and would solve my issue, thanks!

Additionally, and this is just a suggestion without doing too much investigation (so I may be wrong), + in the query string apparently means a space:

https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1

Screenshot 2023-01-24 at 22 50 38

This is what encodeURI does, it preserves + chars.

Anyway, as I said before I'm not sure about this and don't want to invest mucho more time in this issue, so I totally understand (and maybe it's the right thing to do) if you decide to keep the current behavior and just leave the query string alone if it's not modified, which works for me 😊.

Thanks!

<!-- gh-comment-id:1402978997 --> @gabrielmaldi commented on GitHub (Jan 25, 2023): > if you don't modify the query, I will keep reserving the original data without performing the encoding I agree with that and would solve my issue, thanks! Additionally, and this is just a suggestion without doing too much investigation (so I may be wrong), `+` in the query string apparently means a space: https://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.1 <img width="663" alt="Screenshot 2023-01-24 at 22 50 38" src="https://user-images.githubusercontent.com/3728897/214462690-d2fff4bd-068c-4926-9fed-ec3ddfa848ca.png"> This is what `encodeURI` does, it preserves `+` chars. Anyway, as I said before I'm not sure about this and don't want to invest mucho more time in this issue, so I totally understand (and maybe it's the right thing to do) if you decide to keep the current behavior and just leave the query string alone if it's not modified, which works for me 😊. Thanks!
Author
Owner

@NghiaTranUIT commented on GitHub (Jan 28, 2023):

@gabrielmaldi if you don't mind, let's try this beta build: https://proxyman.s3.us-east-2.amazonaws.com/beta/Proxyman_4.1.0_Fix_Scripting_Query_Encoding.dmg

If you don't modify the Query, it will be intact, so the + in your query doesn't encode to %2B.
If you modify the query, it will encode as it's how Apple framework does.

Please let me know if it works for you 👍

<!-- gh-comment-id:1407422763 --> @NghiaTranUIT commented on GitHub (Jan 28, 2023): @gabrielmaldi if you don't mind, let's try this beta build: https://proxyman.s3.us-east-2.amazonaws.com/beta/Proxyman_4.1.0_Fix_Scripting_Query_Encoding.dmg If you don't modify the Query, it will be intact, so the `+` in your query doesn't encode to `%2B`. If you modify the query, it will encode as it's how Apple framework does. Please let me know if it works for you 👍
Author
Owner

@gabrielmaldi commented on GitHub (Jan 28, 2023):

@NghiaTranUIT, can confirm the beta works perfectly. Tested both cases (modifying the query string and leaving it alone) and they work as expected (as you described). So this solves the issue for me, thanks!

Perhaps a feature which would help with these scenarios (where you want to change the protocol, host, port, and path of a request) is for Map Remote to support capturing regular expressions. So then in the Path input you could use something like /another-path/new-api/$1 and $1 would get replaced by whatever you captured in Rule. This is not a feature request as my requirement is already fulfilled by the more general Scripting feature, just a suggestion to maybe add to the backlog if you deem it worthwhile 😊.

I think Proxyman is awesome, love every aspect of it, thanks for creating it, working hard and listening to users! If there is a beta update channel I will happily switch to it and report issues I find. Thanks!

<!-- gh-comment-id:1407437331 --> @gabrielmaldi commented on GitHub (Jan 28, 2023): @NghiaTranUIT, can confirm the beta works perfectly. Tested both cases (modifying the query string and leaving it alone) and they work as expected (as you described). So this solves the issue for me, thanks! Perhaps a feature which would help with these scenarios (where you want to change the protocol, host, port, and path of a request) is for Map Remote to support capturing regular expressions. So then in the Path input you could use something like `/another-path/new-api/$1` and `$1` would get replaced by whatever you captured in Rule. This is not a feature request as my requirement is already fulfilled by the more general Scripting feature, just a suggestion to maybe add to the backlog if you deem it worthwhile 😊. I think Proxyman is awesome, love every aspect of it, thanks for creating it, working hard and listening to users! If there is a beta update channel I will happily switch to it and report issues I find. Thanks!
Author
Owner

@NghiaTranUIT commented on GitHub (Jan 29, 2023):

Thanks for your kind word @gabrielmaldi 🙇

Capture Regular Expression is a huge change. I will consider to support it 👍

<!-- gh-comment-id:1407529435 --> @NghiaTranUIT commented on GitHub (Jan 29, 2023): Thanks for your kind word @gabrielmaldi 🙇 Capture Regular Expression is a huge change. I will consider to support it 👍
Author
Owner

@gabrielmaldi commented on GitHub (Jan 29, 2023):

If it's huge then I'd say forget about it, we can just use Scripting 😊.

<!-- gh-comment-id:1407529653 --> @gabrielmaldi commented on GitHub (Jan 29, 2023): If it's huge then I'd say forget about it, we can just use Scripting 😊.
Author
Owner

@hatalho commented on GitHub (Apr 15, 2024):

This exact same issue still occurs in the current version 2.14 for Windows, is there any way to fix it? Thanks

<!-- gh-comment-id:2054598624 --> @hatalho commented on GitHub (Apr 15, 2024): This exact same issue still occurs in the current version 2.14 for Windows, is there any way to fix it? Thanks
Author
Owner

@NghiaTranUIT commented on GitHub (Apr 16, 2024):

@hatalho I will open a Windows ticket and fix it in the next release 👍

<!-- gh-comment-id:2058053394 --> @NghiaTranUIT commented on GitHub (Apr 16, 2024): @hatalho I will open a Windows ticket and fix it in the next release 👍
Author
Owner

@hatalho commented on GitHub (Jun 14, 2024):

@hatalho I will open a Windows ticket and fix it in the next release 👍

hi @NghiaTranUIT

2 months have passed since your last update, any news? Thanks!

<!-- gh-comment-id:2167861220 --> @hatalho commented on GitHub (Jun 14, 2024): > @hatalho I will open a Windows ticket and fix it in the next release 👍 hi @NghiaTranUIT 2 months have passed since your last update, any news? Thanks!
Author
Owner

@NghiaTranUIT commented on GitHub (Jun 14, 2024):

@kics223w1 can you look on it ?

<!-- gh-comment-id:2168096924 --> @NghiaTranUIT commented on GitHub (Jun 14, 2024): @kics223w1 can you look on it ?
Author
Owner

@hatalho commented on GitHub (Jun 14, 2024):

It seems to be working now, I'll let you know if I run into any difficulties, thanks!

<!-- gh-comment-id:2168166711 --> @hatalho commented on GitHub (Jun 14, 2024): It seems to be working now, I'll let you know if I run into any difficulties, thanks!
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/Proxyman#1506
No description provided.