tunnel.now
tunnel.now copied to clipboard
divmain
Update modules to fix npm audit warning, handle remote url (vs. host), error handling
There are a few changes here:
- Update npm modules to address an npm audit warning about a DoS in WebSocket
Required some API changes to handle backwards compat issues w/ WebSocket.
- Allow specifying a remote url instead of just a remote host
This allows someone to do, for example, local testing by running:
tunnel.now http://localhost:8008 8000
Whereas before, the tunnel server had to be listening on now (https/443) you can now point to it listening anywhere if you wish. In the case were a pure hostname is used (eg foo.now.sh) it will work as it used to.
- There were a couple of error conditions that this tries to handle better:
a) When there is no active connection, we should reply with a 503 and then stop trying to process that request.
b) Sometimes, even when we had a connection, we may no longer be able to reach the forwarded server. In that case, catch fetch() errors and reply with an appropriate response/code.
Oh, I forgot: I went down this rabbit hole trying to fix an issue where headers were not being properly passed. Perhaps fetch, even in a non-major version update, changed their handling? Regardless, using response.headers.raw() appears to resolve the issue.
Useful! I'm working on my own fork, and your e7e4870 is a handy feature I may pull into mine.
My goal is allowing you to set a default hostname and port in a config file so you can quickly spin up tunnels on your preferred custom URL.
On a related note, looks like PRs are dead here.
Feel free to bring this change in. Point me at your fork. This is definitely a useful utility and I'd be happy to contribute if you're planning to actively maintain.
PS I am a bit worried this will not work as Zeit eventually deprecates v1. Translating this to a v2 serverless setup should probably be on the radar.
My fork is unitof/tunnow. As of this morning it's basically working! Just with no documentation, which I hope to add within next week.
Unless we hear from @divmain I'll likely publish as a new npm package, intended for global installation as a CLI tool.
For now I just added a line to explicitly target v1, but exactly as you hinted at: eventual goal is to upgrade it to a v2 lambda, which I'm excited to learn.