![]() 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) |
||
---|---|---|
pkgs | ||
racket | ||
.gitattributes | ||
.gitignore | ||
.mailmap | ||
.travis.yml | ||
appveyor.yml | ||
INSTALL.txt | ||
Makefile | ||
README.md |
This is the source code for the core of Racket. See "INSTALL.txt" for full information on building Racket.
To build the full Racket distribution from this repository, run make
in the top-level directory. To build the Minimal Racket, run make base
.
The rest of the Racket distribution source code is in other repositories under the Racket GitHub organization.
Contribute to Racket by submitting a pull request, joining the development mailing list, or visiting the IRC channel.
License
Racket Copyright (c) 2010-2016 PLT Design Inc.
Racket is distributed under the GNU Lesser General Public License (LGPL). This implies that you may link Racket into proprietary applications, provided you follow the rules stated in the LGPL. You can also modify Racket; if you distribute a modified version, you must distribute it under the terms of the LGPL, which in particular states that you must release the source code for the modified software.
See racket/src/COPYING_LESSER.txt for more information.