starred/Proxyman

Fork 0

mirror of https://github.com/ProxymanApp/Proxyman.git synced 2026-04-26 08:35:53 +03:00

[GH-ISSUE #585] Local Map error #582

New issue

Closed

opened 2026-03-03 19:20:00 +03:00 by kerem · 5 comments

kerem commented

2026-03-03 19:20:00 +03:00

Owner

Originally created by @yaroslavyaroslav on GitHub (Aug 18, 2020).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/585

Originally assigned to: @NghiaTranUIT on GitHub.

Proxyman version? (Ex. Proxyman 1.4.3)

2.4.1

macOS Version? (Ex. mac 10.14)

macOS 10.15.6

Steps to reproduce

Create map local rule with following content:

HTTP/1.1 200 OK
Server: nginx
Date: Tue, 18 Aug 2020 14:45:06 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 36
Connection: keep-alive
TraceId: ce1b7a988dc331f94aa5e176c6c6fbe0
api-supported-versions: 1.0
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Request-ID: a796bb47419f2d00e42a5c0d1c3a051d
Strict-Transport-Security: max-age=157680000

{"status":"sNotFound","payload":null}

It'll will show that the content is broken. (and response on the request with broken one). If you delete one letter (any) in json it will show that the content is correct.
Seems that there's some content length problem.

Expected behavior

It should not corrupt long responses.

Screenshots (optional)

Originally created by @yaroslavyaroslav on GitHub (Aug 18, 2020). Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/585 Originally assigned to: @NghiaTranUIT on GitHub. ### Proxyman version? (Ex. Proxyman 1.4.3) 2.4.1 ### macOS Version? (Ex. mac 10.14) macOS 10.15.6 ### Steps to reproduce Create map local rule with following content: ``` HTTP/1.1 200 OK Server: nginx Date: Tue, 18 Aug 2020 14:45:06 GMT Content-Type: application/json; charset=utf-8 Content-Length: 36 Connection: keep-alive TraceId: ce1b7a988dc331f94aa5e176c6c6fbe0 api-supported-versions: 1.0 X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Strict-Transport-Security: max-age=31536000; includeSubDomains; preload X-Request-ID: a796bb47419f2d00e42a5c0d1c3a051d Strict-Transport-Security: max-age=157680000 {"status":"sNotFound","payload":null} ``` It'll will show that the content is broken. (and response on the request with broken one). If you delete one letter (any) in json it will show that the content is correct. Seems that there's some content length problem. ### Expected behavior It should not corrupt long responses. ### Screenshots (optional) ![Снимок экрана 2020-08-18 в 18 54 10](https://user-images.githubusercontent.com/16612247/90536484-cc6f4b80-e184-11ea-8932-c3cef900b81b.png) ![Снимок экрана 2020-08-18 в 18 53 44](https://user-images.githubusercontent.com/16612247/90536496-ced1a580-e184-11ea-834d-53d74a6158aa.png)

kerem

2026-03-03 19:20:00 +03:00

closed this issue
added the
✅ Done
label

kerem commented

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

Author

Owner

@NghiaTranUIT commented on GitHub (Aug 19, 2020):

Thanks. I understand your problem. The problem is your Content-Length doesn't match with the body's length.

I'm using HTTPParser to parse this HTTP Message, let see how can I modify the code and ignore the Check condition on the Content-Length 👍

@NghiaTranUIT commented on GitHub (Aug 19, 2020): Thanks. I understand your problem. The problem is your Content-Length doesn't match with the body's length. I'm using [HTTPParser](https://github.com/nodejs/http-parser) to parse this HTTP Message, let see how can I modify the code and ignore the Check condition on the Content-Length 👍

kerem commented

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

Author

Owner

@NghiaTranUIT commented on GitHub (Aug 19, 2020):

Hi @yaroslavyaroslav, after investigation, I suppose that it's a correct behavior. Because you explicitly define the number of Content-Length and it doesn't match with the Body's length -> Thus, you get the error as expected.

If I follow you suggestion, it's incorrect since the HTTP Message requires the ContentLength must be equal with the Body Length.

I will improve the error message, so make it's clearer to the users

On the other hand, If you create the Map Local by Right-Click on the Request -> Tools -> Map Local -> Proxyman will attempt to remove:

Transfer-Encoding
Content-Length
because it causes unexpected trouble, but it will add later when composing the final Response.

@NghiaTranUIT commented on GitHub (Aug 19, 2020): Hi @yaroslavyaroslav, after investigation, I suppose that it's a correct behavior. Because you **explicitly** define the number of Content-Length and it doesn't match with the Body's length -> Thus, you get the error as expected. If I follow you suggestion, it's incorrect since the HTTP Message **requires** the ContentLength must be equal with the Body Length. I will improve the error message, so make it's clearer to the users <img width="1648" alt="Screen_Shot_2020-08-19_at_09_56_16" src="https://user-images.githubusercontent.com/5878421/90587227-067f3280-e203-11ea-9f98-12730c20216e.png"> On the other hand, If you create the Map Local by Right-Click on the Request -> Tools -> Map Local -> Proxyman will attempt to remove: - Transfer-Encoding - Content-Length because it causes unexpected trouble, but it will add later when composing the final Response.

kerem commented

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

Author

Owner

@NghiaTranUIT commented on GitHub (Aug 19, 2020):

If you would try a beta build: Here you go https://proxyman.s3.us-east-2.amazonaws.com/beta/Proxyman_2.4.1_Better_ContentLength_Error_Message.dmg 👍

@NghiaTranUIT commented on GitHub (Aug 19, 2020): If you would try a beta build: Here you go https://proxyman.s3.us-east-2.amazonaws.com/beta/Proxyman_2.4.1_Better_ContentLength_Error_Message.dmg 👍

kerem commented

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

Author

Owner

@yaroslavyaroslav commented on GitHub (Aug 19, 2020):

Oh, my bad, haven't checked headers well. Yep, in that case I think more precise error message will be great. Thank you.

@yaroslavyaroslav commented on GitHub (Aug 19, 2020): Oh, my bad, haven't checked headers well. Yep, in that case I think more precise error message will be great. Thank you.

kerem commented

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

Author

Owner

@NghiaTranUIT commented on GitHub (Aug 19, 2020):

Don't worry. Glad to know that it resolves your case 🎉

@NghiaTranUIT commented on GitHub (Aug 19, 2020): Don't worry. Glad to know that it resolves your case 🎉