I like this idea too. I think it'd be confusing to use a / to separate the subdomain and path. Do you know of another symbol that would be easier to use? For example, @ isn't traditionally used inside of URLs other than to signify basic auth creds, therefore, we could signify the domain as ssh -R this/is/path@subdomain:443:localhost:8080 ssi.sh or something like that?

I don't mind using the @. My main goal is that this doesn't break existing usages by using some char that doesn't practically work in a subdomain. In combination with #166 it may look a bit awkward to use bar@:443:localhost:8080 (vs /bar:443:localhost:8080), which is my practical usage (just one domain with paths to eliminate the wildcard need).

@bibo38 true, but I just realized you can already set the same domain. All you need to do is:

1. Set --redirect-root to false so that requests to the root domain aren't redirected
2. Use --bind-any-host or setup the TXT record for the domain to allow it to be bound
3. Provide the root domain entirely ssh -R ssi.sh:80:localhost:8080 ssi.sh
   So if we leave it explicitly defined rather than empty is evaluated as the root, then the @ wouldn't look weird.

When providing the root domain entirely, the / option get's even better (bar@ssi.sh:443:localhost:8080 vs ssi.sh/bar:443:localhost:8080, you can even do foo.ssi.sh/bar:443:localhost:8080) 😏 . I don't mind the awkward look that i mentioned in my last comment, but I do want to have the ability to omit the domain name (less typing), so supporting bar@:443:localhost:8080 would be fine for me.

Quick idea: Maybe we can support both symbols/ideas (i've omit the :443:localhost:8080 trailer):

• /bar goes to ssi.sh/bar, for consistency this also works on nested paths (/this/is/path -> ssi.sh/this/is/path)
• For subdomains you add the @. E.g. /this/is/path@foo -> foo.ssi.sh/this/is/path
• Explicit domain can be done both ways, so foo.ssi.sh/this/is/path and /this/is/path@foo.ssi.sh are equivalent and point to foo.ssi.sh/this/is/path

The explicit / prefix indicates that you specify a path and not a subdomain and is mandatory. So this/is/path:443:localhost:8080 will be handled as it currently works (returning the unusable url https://this/is/path.ssi.sh).

Edit: foo@bar:443:localhost:8080 will also be undefined behaviour, maybe resulting in foobar.ssi.sh or foo.bar.ssi.sh or foo@bar.ssi.sh