mirror of
https://github.com/ProxymanApp/Proxyman.git
synced 2026-04-25 16:15:55 +03:00
[GH-ISSUE #274] Response breakpoints not working as expected. #269
Labels
No labels
Discussion
Feature request
In Progress...
Plugins
Waiting response
Windows
Windows
bug
duplicate
enhancement
feature
good first issue
iOS
macOS 10.11
question
wontfix
✅ Done
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Proxyman#269
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @drekka on GitHub (Sep 9, 2019).
Original GitHub issue: https://github.com/ProxymanApp/Proxyman/issues/274
Proxyman version? (Ex. Proxyman 1.4.3)
1.6.0
macOS Version? (Ex. mac 10.14)
10.14.6
Steps to reproduce
Expected behavior
Proxyman will break on the request coming back from the local host server and wait for the response to be edited.
Actual behaviour
Proxyman displays the response in the Breakpoint window, then after about 5 seconds auto-continues before I've had a change to look or edit it.
Some thoughts
Apart from the above bug, I also found the breakpoints UI a little confusing. For example, on the Breakpoints window there is a 'Add Rule' button below the list of breakpoints. At first I thought that I had to use this to add a break point. I didn't realised it was a a different thing b ecause it's position below the list suggested to me it would add something to it.
I'd actually like to suggest changing the list of breakpoints to be a tree view, with the rules listed and the active breakpoint appearing (and disappearing) under the relevant rule. This would make easier and clearer to understand (IMHO), plus the add rule dialog would no be needed, just the dialog for editing a rule.
@NghiaTranUIT commented on GitHub (Sep 9, 2019):
Thank for the feedback. I observers that the socket could be closed for some reasons (Timeout or bugs in the CocoaAsyncSocket) and it automatically close the Tunnel and the response is gone. Thus, It causes frustration.
I will investigate in this release.
Regarding your thought, it's super valuable feedback. Thank you so much for the insight 👍
I would make the breakpoint as a tree view, the note is the matched rule, and sub-list is list of breakpoint. Good sense for it 👍
@NghiaTranUIT commented on GitHub (Sep 9, 2019):
Hot-fix build at https://github.com/ProxymanApp/Proxyman/issues/272#issuecomment-529538637 also including the UI change to indicate whenever the macOS proxy is enable/disable by the state button in Bottom-Left of windows.
At the first though, I would put it in the ToolBar, but its confusing to have 2 similar buttons. Thus, I would keep the simple as it is and move the indicate to bottom toolbar. 👍
@drekka commented on GitHub (Sep 11, 2019):
I like the idea having a button. Probably just before the start/stop button. I'm thinking you could use the standard power icon for starting and stopping proxying (installing settings) and continuing user the standard play/pause icons for starting and stopping recording.
As a further note, I noticed that I could set and unset the proxy settings completely independently of the start/stop action. I'd suggest that if the user unsets the proxy settings, then Proxyman should also pause any recording because it makes no sense to me that it should appear to still be recording if it's no longer proxying. :-)
@NghiaTranUIT commented on GitHub (Dec 3, 2019):
Hey @drekka,
Sorry for being so long because I haven't reproduced it yet since that day.
Here is the hot-fix BETA build for you: https://proxyman.s3.us-east-2.amazonaws.com/beta/Proxyman_1.9.3_Breakpoint_Issues.dmg
Technically, the request has connection: close so it close the connection immediately during editing the breakpoint => I override it to keep-alive and it works as we expected 🌮
I will rollout the fix in this week 👍
@drekka commented on GitHub (Dec 4, 2019):
Thanks. That's great. I'll try and give it a go in the next eww days. Am a bit busy too at the moment :-)
@NghiaTranUIT commented on GitHub (Dec 4, 2019):
Thank for that 👍
@drekka commented on GitHub (Dec 6, 2019):
Unfortunately it's not working here. I ran a rule of "http://localhost%3A5050/*". ProxyMan hit the break point as expected, but didn't actually stop the response and the breakpoint disappears after about 5 - 10 seconds.
I also noticed to that ports are using the characters "%3A" instead of ":", so I'm seeing URLs like http://localhost%3A5050/... instead of http://localhost:5050/... I had to use the "%3A" in the break points as well.
Finally something else which I'm not sure if it's me or not. If I click Certificate - Install Certificate on iOS Simulators ... it shows the root certs in this Mac as installed and trusted, but simulators as not being installed. I tap "Install to iOS Simulators" (wait for it to go green) then "Reset all iOS Simulators" and wait for them to reboot. But when I come back into this dialog it's still showing the simulators as needing certs. I also tried just adding the certs but it still shows them as not added when I come back to the certs dialog.
@NghiaTranUIT commented on GitHub (Dec 6, 2019):
Regarding the iOS Simulator, it's a limitation because we don't know how many iOS simulators are installed the certificated. When you hit "Install to iOS Simulator", it means it would install to all visible simulators (other simulators (different iOS version or device types) are not installed).
I suppose that I should improve this screen by adding the Description to show that which devices are installed. For instance: ✅ Installed on iPhone X (iOS 11.1), iPhone X (iOS 10.1) simulators.
Thus, it's clear that you have installed successfully in certain device, but you can also install for the another if needed
@NghiaTranUIT commented on GitHub (Dec 6, 2019):
Regarding the breakpoint, if it dismiss after 5-10 seconds, can you double check
Connectionheader in the request? (keep-aliveorclose)Because if it dismiss after 5-10 seconds, it looks like the connection is break by timeout from the client.
@drekka commented on GitHub (Dec 17, 2019):
Sorry, been very busy. Will get back on this when I can :-)
@NghiaTranUIT commented on GitHub (Dec 17, 2019):
Thank for that @drekka.
Before the Breakpoint fix in Proxyman 1.10.0, Breakpoint would break as soon as it is connected (if the
Connectionheader ==close). Therefore, if it closes with a delay 5-10 seconds, it looks like by a Timeout.@NghiaTranUIT commented on GitHub (Dec 18, 2019):
Hi @drekka
Here is the fix for Response Breakpoint https://proxyman.s3.us-east-2.amazonaws.com/beta/Proxyman_1.10.0_Fix_Breakpoint_Timeout.dmg
As the connection is closed due to timeout, so the Response will be disappears after 2 seconds. In this fix, I deliberately keep the connection alive and it should work 👍
I will roll out officially the fix tmr.
@NghiaTranUIT commented on GitHub (Dec 19, 2019):
Hey @drekka just friendly reminder that I released Proxyman 1.11.0, which actually fix the Breakpoint issues. Let check it out 👍
@drekka commented on GitHub (Jan 6, 2020):
Thanks, will try it soon. Busy busy busy :-)
@drekka commented on GitHub (Jan 15, 2020):
Just tried it in 1.13.1 and it looks to be working perfectly. Well done.
@NghiaTranUIT commented on GitHub (Jan 15, 2020):
Thank you for informing 🎉