starred/Proxyman

Fork 0

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

[GH-ISSUE #488] Failed/Hanging HEAD requests that work correctly with Charles Proxy #486

New issue

Closed

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

kerem commented

2026-03-03 19:19:12 +03:00

Owner

Originally created by @christos on GitHub (Apr 27, 2020).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/488

Originally assigned to: @NghiaTranUIT on GitHub.

Proxyman version? (Ex. Proxyman 1.4.3)

Proxyman 1.22.0

macOS Version? (Ex. mac 10.14)

MacOS 10.15.4 (19E287)
iOS 13.4.1

Steps to reproduce

I am trying to use Proxyman to replace CharlesProxy. I am using it to sniff the traffic my company's app sends to our API server. I've successfully installed the Certificate and I am able to intercept and read all SSL traffic with an exception of a single endpoint.

We do a HEAD /whoami request from the app to ensure our API is down and otherwise display the "offline" mode.

I would expect this endpoint to work the same as the other endpoints.

With the same setup/app in CharlesProxy the request/response is:

:method: HEAD
:scheme: https
:path: /whoami
:authority: api.xxxxxxxxx.com
accept: */*
pragma: no-cache
user-agent: lingokids/3170 CFNetwork/1125.2 Darwin/19.4.0
cache-control: no-cache, no-store, must-revalidate
accept-encoding: gzip, deflate, br
accept-language: en-us
content-length: 0
expires: 0

:status: 200
content-type: text/plain; charset=utf-8
content-length: 0
server: awselb/2.0
date: Mon, 27 Apr 2020 17:17:07 GMT
x-cache: Miss from cloudfront
via: 1.1 xxxxxxxxxxxxxxxx.cloudfront.net (CloudFront)
x-amz-cf-pop: MAD50-C1
x-amz-cf-id: 6bZhiduF1GPJctkLp00CU7mPQs6GOfB276RExgRPvPyu0K9F_UeelA==

With Proxyman I get two behaviours in no particular order:

As you can see instead of the path /whoami it either gets stuck in CONNECT of fails with Client SSL Handsake Failed (which it shouldn't because the requests around it t to the same host work correctly)

Expected behaviour

I would expect it to work correctly like it does in CharlesProxy.

Screenshots (optional)

Provided inline.

Endpoint was redacted but I can provide more info, access to the endpoint and app privately.

Originally created by @christos on GitHub (Apr 27, 2020). Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/488 Originally assigned to: @NghiaTranUIT on GitHub. ### Proxyman version? (Ex. Proxyman 1.4.3) Proxyman 1.22.0 ### macOS Version? (Ex. mac 10.14) MacOS 10.15.4 (19E287) iOS 13.4.1 ### Steps to reproduce I am trying to use Proxyman to replace CharlesProxy. I am using it to sniff the traffic my company's app sends to our API server. I've successfully installed the Certificate and I am able to intercept and read all SSL traffic with an exception of a single endpoint. We do a `HEAD /whoami` request from the app to ensure our API is down and otherwise display the "offline" mode. I would expect this endpoint to work the same as the other endpoints. With the same setup/app in CharlesProxy the request/response is: ``` :method: HEAD :scheme: https :path: /whoami :authority: api.xxxxxxxxx.com accept: */* pragma: no-cache user-agent: lingokids/3170 CFNetwork/1125.2 Darwin/19.4.0 cache-control: no-cache, no-store, must-revalidate accept-encoding: gzip, deflate, br accept-language: en-us content-length: 0 expires: 0 ``` ``` :status: 200 content-type: text/plain; charset=utf-8 content-length: 0 server: awselb/2.0 date: Mon, 27 Apr 2020 17:17:07 GMT x-cache: Miss from cloudfront via: 1.1 xxxxxxxxxxxxxxxx.cloudfront.net (CloudFront) x-amz-cf-pop: MAD50-C1 x-amz-cf-id: 6bZhiduF1GPJctkLp00CU7mPQs6GOfB276RExgRPvPyu0K9F_UeelA== ``` With Proxyman I get two behaviours in no particular order: <img width="1028" alt="Screenshot 2020-04-27 at 19 25 35" src="https://user-images.githubusercontent.com/736/80403381-c8f74200-88bf-11ea-923c-1769226f9f46.png"> <img width="1214" alt="Screenshot 2020-04-27 at 19 25 41" src="https://user-images.githubusercontent.com/736/80403367-c5fc5180-88bf-11ea-9cbe-b4c25f508f7a.png"> <img width="1216" alt="Screenshot 2020-04-27 at 19 24 10" src="https://user-images.githubusercontent.com/736/80403377-c85eab80-88bf-11ea-8497-5a700622dae7.png"> As you can see instead of the path `/whoami` it either gets stuck in `CONNECT` of fails with `Client SSL Handsake Failed` (which it shouldn't because the requests around it t to the same host work correctly) ### Expected behaviour I would expect it to work correctly like it does in CharlesProxy. ### Screenshots (optional) Provided inline. Endpoint was redacted but I can provide more info, access to the endpoint and app privately.

kerem

2026-03-03 19:19:12 +03:00

closed this issue
added the
bug

✅ Done
labels

kerem commented

2026-03-03 19:19:13 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Apr 28, 2020):

I love how it's useful to me for reproducing the bug 🌮. Thanks for the detail bug report.

Confirmed that Proxyman is buggy for the HEAD request. I'm fixing it now 👍

@NghiaTranUIT commented on GitHub (Apr 28, 2020): I love how it's useful to me for reproducing the bug 🌮. Thanks for the detail bug report. Confirmed that Proxyman is buggy for the HEAD request. I'm fixing it now 👍

kerem commented

2026-03-03 19:19:13 +03:00

Author

Owner

@NghiaTranUIT commented on GitHub (Apr 28, 2020):

Technically, the response of the HEAD request doesn't contain the Body so Proxyman just wait for the response.

@christos let try this BETA: https://proxyman.s3.us-east-2.amazonaws.com/beta/Proxyman_1.22.0_HEAD_Request_Bug.dmg

The bug should be squashed 🐞

@NghiaTranUIT commented on GitHub (Apr 28, 2020): Technically, the response of the HEAD request doesn't contain the Body so Proxyman just wait for the response. @christos let try this BETA: https://proxyman.s3.us-east-2.amazonaws.com/beta/Proxyman_1.22.0_HEAD_Request_Bug.dmg The bug should be squashed 🐞 <img width="1777" alt="Screen Shot 2020-04-28 at 16 11 46" src="https://user-images.githubusercontent.com/5878421/80469897-6a879d80-896b-11ea-8766-900b69259045.png">

kerem commented

2026-03-03 19:19:13 +03:00

Author

Owner

@christos commented on GitHub (Apr 28, 2020):

@NghiaTranUIT Yup! That build fixes it for me.

Great work on the app, BTW. I am off to get myself a license.

@christos commented on GitHub (Apr 28, 2020): @NghiaTranUIT Yup! That build fixes it for me. Great work on the app, BTW. I am off to get myself a license.