This patch adds https and git proxying through HTTP’s `CONNECT` method.
**Sanity Checks Needed:**
1. Is the git protocol proxying necessary?
It might be overkill, and I haven’t overly tested it since `raco pkg
install` uses https as its transport anyway
2. If anyone is better clued up on HTTP `CONNECT` best practice, then
please check the headers that I pass (in `http-client.rkt`)
3. Is HTTP `CONNECT` the only/best way to proxy HTTPS? It is what *curl*
uses (which might be a good indicator)
4. Will the ports be closed properly? (does anyone see a fid leak?)
- how do I test for that? Open (and allegedly close) 1024 tunnels?
5. The `abandon-p` definitions in `http-conn-CONNECT-tunnel` could
probably be reduced, but they’re defined as they are to allow me to
put debugging hooks in
6. No tests or documentation yet
7. I edited this with *vim*, and therefore the indentation is a la vim.
I looked at doing a global reindent (of git-checkout) and so much
changed that I abandoned that as an idea. It indentation is too
“off-style” then feel free to change it :-)
**git-checkout.rkt:**
- `initial-connect` now tries to use a git proxy (see `url.rkt`, below)
when *transport*=`git`
- (if *transport*=`https`, then `url.rkt`’s standard proxying will be
used)
**http-client.rkt:**
- `http-conn-open!` can now be passed a
`(list/c base-ssl?/c input-port? output-port? (-> port? void?))` to
describe:
- maybe a negotiated ssl context
- two tunnel (or other arbitrary) ports to use instead of newly
`...-connect`ed ports
- an abandon function for those ports
- `http-conn-send!` has a function `print-to` which curries
`(fprintf to)`, but allows a hook for an `eprintf` for debugging
- **added `http-conn-CONNECT-tunnel`:** this opens an new `http-conn`
and arranges for CONNECT tunneling to `target-host` and `target-port`
- factored contracts into `base-ssl?/c` and `base-ssl?-tnl/c`
- added contract for `http-conn-CONNECT-tunnel`
**url.rkt:**
- `proxiable-url-schemes`: now includes `https` and `git`
- `env->c-p-s-entries`: the environment variable “parser” now takes a
rest-list of lists of environment variables, and the scheme that these
variables proxy is garnered from the variables’ names. As before
there are:
- `plt_http_proxy` and `http_proxy`
- `plt_https_proxy` and `https_proxy`
- `plt_git_proxy` and `git_proxy`
during the previous iteration of obtaining the proxy variables at
startup, we discussed the appropriate naming conventions for these
variables. This doesn’t seem to deviate from that
- `env->c-p-s-entries`: having a proxy url that isn’t strictly:
`http://hostname:portno` (e.g. having a training slash) generates a
log warning, not an error. It was beginning to bug me
- `proxy-servers-guard`: accepts any one of the `proxiable-url-schemes`
(not just `http`)
- no proxy is agnostic to the URL scheme
- `proxy-tunneled?`: returns false for `http`, which is proxied using an
HTTP proxy. Returns true for other URL schemes -- which go through a
tunnel
- **`make-ports`:** tests whether a tunnel proxy is necessary. If so, it
creates a tunnel and plumbs the connections
- elsewhere, anywhere that tests for proxy, now tests for
`(and proxy (not proxy-tunneled? url))`, because tunneled HTTPS
connections are direct (once they’re through the tunnel, IYSWIM)
321000b831