Advanced HTTP tunnels

sish can do some advanced things, particularly around routing connections

For example, http forwards can contain custom address information. Let's take a look.

Setup 2 different tunnels in sish:

1.  $ ssh -R test:80:httpbin.org:80 ssi.sh
   
    Starting SSH Forwarding service for http:80. Forwarded connections can be accessed via the following methods:
    Service console can be accessed here: https://test.ssi.sh/_sish/console?x-authorization=CoTWaspHUgLwoYJsaTy2
    HTTP: http://test.ssi.sh
    HTTPS: https://test.ssi.sh

2.  $ ssh -R foo\\:bar@test/blah:80:httpbin.org:80 ssi.sh
   
    Starting SSH Forwarding service for http:80. Forwarded connections can be accessed via the following methods:
    Service console can be accessed here: https://foo:[email protected]/blah/_sish/console?x-authorization=3fIzQLC10rcY18RZLb7p
    HTTP: http://foo:[email protected]/blah
    HTTPS: https://foo:[email protected]/blah

Some magic is happening here. We were able to create 2 different forwards for the same subdomain, but sish is able to differentiate between these two forwards.

Because our first forward has no auth information (prior to the @ symbol) and no path information (after the / symbol), it is the default handler for curl https://test.ssi.sh. If we were to instead send auth information AND the path defined in tunnel 2, sish would forward the connection there: curl https://foo:[email protected]/blah/. Requests to the path alone would still resolve to the tunnel 1, because auth information is required.

If we only setup tunnel 2, sish would ask for basic auth prior to completing the request to https://test.ssi.sh/blah/. If we instead did not provide the path /blah/ to the request, sish would then 404.

This allows users to bind the same domain, but route requests based on auth and path information.