Adding bind address pre-check before starting the default proxy

[cviaggi-actiance]

The LittleProxy code has a bug whereby when you try to bootstrap the proxy against a port that is already in use, it will fail and not cleanup it's resources. If left to run, this can eventually cause the max file descriptors to be reached.

We can't change LittleProxy but we can check to make sure port isn't already in use. In some environments it is not practical to assume the min-max ports will be reserved and unused all the time.

[ericbeland]

I like the idea of this, generally. We are switching to mitm-proxy implementation instead of littleproxy. This might still have value in that context, but I'm not clear on that yet and haven't looked closely.

[cviaggi-actiance]

We currently use BUP in our production environment to intercept and grab HAR files. The issue we were facing is that BUP proxy assumes the port is free and it can bind to it. As it turns out, the Operations Team (some well meaning SRE I’m sure) had installed some other service which was binding to a port in the middle of that range. Littleproxy, if it failed to bind to the port, it wouldn’t clean itself up, resulted in a memory leak, and would eventually crash the system. So as long as mitm-proxy either cleans itself up, or the port is checked as free first, that would ensure there is no memory leak. Thanks, //C From: HereC <[email protected]> Sent: Thursday, December 3, 2020 11:30 AM To: browserup/browserup-proxy <[email protected]> Cc: Chris Viaggi <[email protected]>; Author <[email protected]> Subject: Re: [browserup/browserup-proxy] Adding bind address pre-check before starting the default proxy (#276) [CAUTION] This is an EXTERNAL email. Do not click links or open attachments unless you recognize the sender and know the content is safe. I like the idea of this, generally. We are switching to mitm-proxy implementation instead of littleproxy. This might still have value in that context, but I'm not clear on that yet and haven't looked closely. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbrowserup%2Fbrowserup-proxy%2Fpull%2F276%23issuecomment-738244169&data=04%7C01%7C%7Cab07756dc6cd4f34552608d897c1e388%7C01bc53fb79ca4409b3eda1a5082bdd00%7C1%7C0%7C637426206307744879%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=O8k6ZqTbPEyBsbZOS93%2FBg7OB7ZPM5iopiD5sRbsOyQ%3D&reserved=0>, or unsubscribe<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAJKSUAUCTINLA5PVQQWYYSTSS7RNFANCNFSM4N2WW3TA&data=04%7C01%7C%7Cab07756dc6cd4f34552608d897c1e388%7C01bc53fb79ca4409b3eda1a5082bdd00%7C1%7C0%7C637426206307754870%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4mzuKyjOLMl6caUmGMxkIEaa%2BV7JVntpCIYNqw1X1Ms%3D&reserved=0>.