-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Switch to forwarding based on URL and add TLS forwarding #108
Conversation
I wanted to make sure this would keep working, so I've gone through the upgrade process for the mutable builders and the forwarding changes. I've got everything working except one test with a unix file without a full path specified. Trying to get to the bottom of that before +1'ing here. The WIP branch: ngrok/ngrok-javascript@main...bob/upgrade-ngrok-rust |
Ah, @bobzilladev - I think your unix socket is missing a |
Yeah, I tried that variation but it wasn't happy for the case that is unhappy, which is with a relative path. e.g. |
Relative is probably just off the table. I'll have to do a little preprocessing to convert to absolute path. |
OK, I think I got it fixed. Here's the playground where I fiddled with various formats. |
19c997c
to
3e65ef7
Compare
3e65ef7
to
9ccb9e4
Compare
The changes help a lot, relative unix pathing is good on nodejs again. A couple issues building on windows noted in comments. As you note in the rust playground, you get some odd results if you do pipe with a blank host, or no host and prepending forward slash. I think it's correct but we'll have to be explicit in documentation.
|
9ccb9e4
to
e55db75
Compare
OK, got it building. And I think I covered all of the unix socket and pipe variants in the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Builds cleanly on windows and generates expected pipe names. WIP branch ngrok-nodejs branch passes all tests. lgtm.
Switches us from the explicit tcp, http, and pipe forwarding methods to
accepting a URL. This should make it easier for us to update what
protocols we support without having to change the public API.
Eventually, we'll also be able to forward smarter with regards to tls,
proxyproto, etc. like the agent, but that'll come later.