When using "boringproxy server" it asks for the admin domain. All grand,
but it looks rather strange:
2021/01/05 22:11:05 Starting up
2021/01/05 22:11:05 Enter Admin Domain:
[cursor is here]
It wasn't really clear to me this was asking a question, as it includes
the date like a log message and the cursor is on the next line.
So, change it to just fmt.Print()
Maybe the "starting up" should also be moved a bit further down, but
that would conflict with my other PR 🙃
Before not giving any command didn't really give much feedback beyond
"invalid arguments". This adds a basic usage message, and tells people
that you can use "boringproxy server -h".
I moved the "Starting up" log message because otherwise that would get
printed when asking for "server -h".
I also added error checks for the flag parsing; I think this isn't
*strictly* needed, but I remember running in to problems once by
omitting it (although I've forgotten what that problem was, exactly).
This is useful for systems like Android which doesn't follow
normal DNS conventions like /etc/resolv.conf, so normal golang
DNS (ie when CGO_ENABLED=0) fails on Android.
Also fixed a bug where client TLS termination was failing to get
new certs I believe because the TLS listener hadn't started up
yet. I didn't notice it before because I'm running the client and
server on the same machine and the server currently gets certs on
startup even for non-server TLS tunnels
Basically working, but still needs:
* UI for selecting TLS passthrough
* Client Let's Encrypt integration for automatically getting certs.
* More testing. The changes were pretty invasive.
Can now put "https://" in front of Client Address to force it to
use TLS. It doesn't do any verification of the upstream cert. This
is intended to work similarly to the way ngrok does it:
https://ngrok.com/docs#http-local-https
Client seems to be working when run manually with adb shell from
/data/local/tmp/ on a Moto G Power. Server fails when trying to
write /.local for the certs.
Services like Jellyfin weren't working apparently because the upstream
requests were using chunked encoding. Reading the entire request body
and forwarding it on seems to fix it.
Also overriding the Host header for upstream requests.
