[GH-ISSUE #380] Quick Map Local

kerem commented

2026-03-03 19:17:59 +03:00

Owner

Originally created by @dutzi on GitHub (Jan 22, 2020).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/380

Originally assigned to: @NghiaTranUIT on GitHub.

Hey,

First I wanted say how nice of a product this is! It's very slick and modern, good job!

I have the following feature suggestion.

My main use case for Proxyman is modifying responses (using Map Local).

The current workflow for this use case is to:

Open the response for a request in my editor, make the changes I need and save it as a new file.
In Proxyman right click the request, then Tools → Map Local...
Click on Select File.
Choose the file I created.
Click on Done
Click on Done again.

This is a bit cumbersome and for my use case, which I perform regularly, takes longer time than needed.

My idea is:

Under Tools (in the request's context menu) add the Option "Quick Map" (or something like that)
Once clicked, Proxyman would create a temporary file whose content is the request's response body, and the file's extension would be based on the response's content type, for example, .css for text/css.
Proxyman will will then open that file (using the OS's default editor), and
Proxyman would map that temporary file to that request.

That way, for said use case, all the user has to do is right click the request, Tools → Quick Map, make the changes within the editor and save the file.

Originally created by @dutzi on GitHub (Jan 22, 2020). Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/380 Originally assigned to: @NghiaTranUIT on GitHub. Hey, First I wanted say how nice of a product this is! It's very slick and modern, good job! I have the following feature suggestion. My main use case for Proxyman is modifying responses (using Map Local). The current workflow for this use case is to: 1. Open the response for a request in my editor, make the changes I need and save it as a new file. 2. In Proxyman right click the request, then Tools → Map Local... 3. Click on Select File. 4. Choose the file I created. 5. Click on Done 6. Click on Done again. This is a bit cumbersome and for my use case, which I perform regularly, takes longer time than needed. My idea is: - Under Tools (in the request's context menu) add the Option "Quick Map" (or something like that) - Once clicked, Proxyman would create a temporary file whose content is the request's response body, and the file's extension would be based on the response's content type, for example, .css for text/css. - Proxyman will will then open that file (using the OS's default editor), and - Proxyman would map that temporary file to that request. That way, for said use case, all the user has to do is right click the request, Tools → Quick Map, make the changes within the editor and save the file.

kerem added the

✅ Done

Feature request

labels

2026-03-03 19:17:59 +03:00

kerem commented

2026-03-03 19:18:00 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 22, 2020):

Hi @dutzi, thank for the detail feedback.

Your proposal is same what we are working on the Local Map v2 (https://github.com/ProxymanApp/Proxyman/issues/345) and the progress is 70% done.

Basically, you can quick map from current Response (if it's available) or a file and capability to edit directly in Proxyman without jumping to other Editor 😄

The goal is reduce the number steps of doing Local Map 👍

I'm spending the Tet holiday to finalize this feature. Please stay tuned ✊

@NghiaTranUIT commented on GitHub (Jan 22, 2020): Hi @dutzi, thank for the detail feedback. Your proposal is same what we are working on the Local Map v2 (https://github.com/ProxymanApp/Proxyman/issues/345) and the progress is 70% done. Basically, you can quick map from current Response (if it's available) or a file and capability to edit directly in Proxyman without jumping to other Editor 😄 The goal is reduce the number steps of doing Local Map 👍 I'm spending the Tet holiday to finalize this feature. Please stay tuned ✊

kerem commented

2026-03-03 19:18:00 +03:00

Author

Owner

@dutzi commented on GitHub (Jan 22, 2020):

That's great!

But plz plz plz have an option to open in native editor, there's so many features i use within it for tasks like these :)

@dutzi commented on GitHub (Jan 22, 2020): That's great! But plz plz plz have an option to open in native editor, there's so many features i use within it for tasks like these :)

kerem commented

2026-03-03 19:18:00 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 23, 2020):

For sure, v2 Map Local must be super convenience 🙌

@NghiaTranUIT commented on GitHub (Jan 23, 2020): For sure, v2 Map Local must be super convenience 🙌

kerem commented

2026-03-03 19:18:00 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 27, 2020):

Hey @dutzi

Let check it out a new release, which including a v2 Map Local 🙌 (https://github.com/ProxymanApp/Proxyman/releases/tag/1.15.0)

From now, we can:

Map from a HTTP Message => Able to change the Status Code, Headers and Body Content
Map from a local file as usual
Auto generate the local file from the current Response (per your request 👍 )
...

Let check it out 😄

@NghiaTranUIT commented on GitHub (Jan 27, 2020): Hey @dutzi Let check it out a new release, which including a v2 Map Local 🙌 (https://github.com/ProxymanApp/Proxyman/releases/tag/1.15.0) <img width="1936" alt="Screen_Shot_2020-01-27_at_20_02_14" src="https://user-images.githubusercontent.com/5878421/73178927-ded05c00-4144-11ea-8b19-f02fd9b6c8db.png"> From now, we can: - Map from a HTTP Message => Able to change the Status Code, Headers and Body Content - Map from a local file as usual - Auto generate the local file from the current Response (per your request 👍 ) - ... Let check it out 😄

kerem commented

2026-03-03 19:18:00 +03:00

Author

Owner

@dutzi commented on GitHub (Jan 27, 2020):

Amazing! Checking it now!

@dutzi commented on GitHub (Jan 27, 2020): Amazing! Checking it now!

kerem commented

2026-03-03 19:18:00 +03:00

Author

Owner

@dutzi commented on GitHub (Jan 27, 2020):

It's sooo much better, I really like it. Thank you.

The only thing I'd change is to comment out the headers within json/js responses.

What I mean is that instead of having a locally mapped .json file look like:

HTTP/1.1 200 OK
Access-Control-Allow-Credentials: true
...more headers
Vary: Accept-Encoding

{"someKey": "someValue"}

Have it look like:

// HTTP/1.1 200 OK
// Access-Control-Allow-Credentials: true
// ...more headers
// Vary: Accept-Encoding

{"someKey": "someValue"}

The reason being is that without the commented out headers the file isn't a legit JSON file (same goes for JS/CSS/etc...). By commenting out the lines we make it compatible with JSON 5 schema IIRC.

The reason for making it confine to the schema is that other tools, like linters or prettiers could still run on the file when using an external editor like VSCode. Prettiers in particual are pretty awesome tools, I have mine set up to run each time I hit Save in VSCode, which means that after I hit Save instead of one long line of JSON I get a formatted JSON instantly.

A holistic solution might require some effort since it should be applied to the most common content-types, so I see why it's probably going to the backlog.

Anyways, again, thank you.

@dutzi commented on GitHub (Jan 27, 2020): It's sooo much better, I really like it. Thank you. The only thing I'd change is to comment out the headers within json/js responses. What I mean is that instead of having a locally mapped .json file look like: ```json HTTP/1.1 200 OK Access-Control-Allow-Credentials: true ...more headers Vary: Accept-Encoding {"someKey": "someValue"} ``` Have it look like: ```json // HTTP/1.1 200 OK // Access-Control-Allow-Credentials: true // ...more headers // Vary: Accept-Encoding {"someKey": "someValue"} ``` The reason being is that without the commented out headers the file isn't a legit JSON file (same goes for JS/CSS/etc...). By commenting out the lines we make it compatible with JSON 5 schema IIRC. The reason for making it confine to the schema is that other tools, like linters or prettiers could still run on the file when using an external editor like VSCode. Prettiers in particual are pretty awesome tools, I have mine set up to run each time I hit Save in VSCode, which means that after I hit Save instead of one long line of JSON I get a formatted JSON instantly. A holistic solution might require some effort since it should be applied to the most common content-types, so I see why it's probably going to the backlog. Anyways, again, thank you.

kerem commented

2026-03-03 19:18:00 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 27, 2020):

Unfortunately, if we add //, it's not a proper the HTTP Message anymore. Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages

Maybe the extension of the file is json, which is automatically created, seems not correct. At the initial implementation, I choose txt, but some Editors (VSCode) doesn't highlight. Otherwise, json ext works well.

You're right that if I save as a json, it's not a legit JSON files anymore.

I check other tools. Some have the Map Local tool from HTTP Message too, but no highlight, which is really bad for my eyes 👀

@NghiaTranUIT commented on GitHub (Jan 27, 2020): Unfortunately, if we add `//`, it's not a proper the HTTP Message anymore. Ref: https://developer.mozilla.org/en-US/docs/Web/HTTP/Messages Maybe the extension of the file is `json`, which is automatically created, seems not correct. At the initial implementation, I choose `txt`, but some Editors (VSCode) doesn't highlight. Otherwise, `json` ext works well. You're right that if I save as a `json`, it's not a legit JSON files anymore. ----------------- I check other tools. Some have the Map Local tool from HTTP Message too, but no highlight, which is really bad for my eyes 👀

kerem commented

2026-03-03 19:18:00 +03:00

Author

Owner

@dutzi commented on GitHub (Jan 27, 2020):

Oh, I see... I wasn't aware that there was an HTTP Message standard. Maybe an extension to VSCode (or whatever IDE) might help here. I'll check if one exists for HTTP Message.

Regarding the extension, for syntax highlighting, I'd keep it as json.

@dutzi commented on GitHub (Jan 27, 2020): Oh, I see... I wasn't aware that there was an HTTP Message standard. Maybe an extension to VSCode (or whatever IDE) might help here. I'll check if one exists for HTTP Message. Regarding the extension, for syntax highlighting, I'd keep it as `json`.

kerem commented

2026-03-03 19:18:00 +03:00

Author

Owner

@dutzi commented on GitHub (Jan 27, 2020):

No extension for HTTP Message... I guess the best workflow for my use-case would be to delete the request's head, save the file (which triggers prettier), copy the formatted JSON, undo until the request's head is back and paste the formatted JSON over the single-line one.

Update: I found this one it implements an HTTP client in VSCode, and offers syntax highlighting to files with http extension. Not very relevant, but still interesting.

@dutzi commented on GitHub (Jan 27, 2020): No extension for HTTP Message... I guess the best workflow for my use-case would be to delete the request's head, save the file (which triggers prettier), copy the formatted JSON, undo until the request's head is back and paste the formatted JSON over the single-line one. **Update:** I found [this one](https://marketplace.visualstudio.com/items?itemName=humao.rest-client) it implements an HTTP client in VSCode, and offers syntax highlighting to files with `http` extension. Not very relevant, but still interesting.

kerem commented

2026-03-03 19:18:00 +03:00

Author

Owner

@dutzi commented on GitHub (Jan 27, 2020):

Will you consider creating two files, one for the HTTP Request's head and another for the body? Is it common practice in other cases?

@dutzi commented on GitHub (Jan 27, 2020): Will you consider creating two files, one for the HTTP Request's head and another for the body? Is it common practice in other cases?

kerem commented

2026-03-03 19:18:00 +03:00

Author

Owner

@yauheniprakapenka commented on GitHub (Jan 27, 2020):

Does anyone work map local in 1.15?

The problem was in the dynamic parameter passed in the request. This is my carelessness.
Thank you for the best proxy in the world!

@yauheniprakapenka commented on GitHub (Jan 27, 2020): > Does anyone work map local in 1.15? The problem was in the dynamic parameter passed in the request. This is my carelessness. Thank you for the best proxy in the world!

kerem commented

2026-03-03 19:18:01 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 27, 2020):

Do you encounter any issue on Map Local @yauheniprakapenka 🤔

@NghiaTranUIT commented on GitHub (Jan 27, 2020): Do you encounter any issue on Map Local @yauheniprakapenka 🤔

kerem commented

2026-03-03 19:18:01 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Jan 27, 2020):

@dutzi I wouldn't consider to separate into 2 files since it's really cumbersome and increase the complex of the code implementation from me and the end-user too (Since you have to select 2 files in order to change the header and the body).

@NghiaTranUIT commented on GitHub (Jan 27, 2020): @dutzi I wouldn't consider to separate into 2 files since it's really cumbersome and increase the complex of the code implementation from me and the end-user too (Since you have to select 2 files in order to change the header and the body).

Rows
Columns

[GH-ISSUE #380] Quick Map Local #379