moosingin3space / hyproxy Goto Github PK

I'd like it to be easy as possible to set up TLS with Hyproxy. Built-in Let's Encrypt support, Caddy-style, would be awesome.

Right now, hyproxy's event loop is single-threaded. In order to match the performance of other reverse proxies, hyproxy will need to use a multi-threaded event loop.

Depends on #2.

There should be some sort of CI running unit tests.

This will probably require more modularity in the code.

When Hyper makes a release that includes tokio support, pin its version in Cargo.toml.

One thing that none of the prevailing reverse proxy solutions except for Traefik handle the need for an elastic (or previously unknown) set of upstream servers. A compelling feature for hyproxy would be the ability to be able to resolve DNS on the fly (and cache the collection of servers for a short time) for upstreams. Varnish-Goto can do that, but even it isn't quite as flexible as I'd like for our kubernetes cluster, where the proxy may not know that an endpoint exists before I synthesize the upstream dns name.

Example :
inbound request:
host: foosvc.loadbalancer.mycluster.org
Gets translated to Kubernetes local service as the upstream address:
foosvc.svc.default.cluster.local

(we don't know that foosvc exists until we receive a request for it)

I understand that it is absolutely not trivial, and would likely require a concurrent thread that is curating the resulting pools of URL -> IP address mappings. But it it had such a feature, it would become immediately useable in any kubernetes, docker-swarm, or mesosphere cluster with almost 0 configuration. And no need to communicate with the cluster oracles.

See body_image.

An integration could enable Hyproxy to have similar features to nginx as a reverse proxy, where it can reduce proxied server connections by buffering to disk.

Just for the "Static files support" goal, the master branch (candidate for body_image 0.4.0 release) now has zero-copy/async. support for memory mapped http bodies using (glibc) madvise(SEQUENTIAL) (for aggressive OS read-ahead), and using tokio-threadpool blocking annotation.

With more work, body_image could be part of a disk-based proxy caching solution ala varnish.

Would you consider such and integration? Thanks!

As mentioned on reddit: I noticed you have "static file serving" described as a required feature for a 1.0 release.

A plug: https://github.com/scottlamb/http-entity is intended to be useful for this: it handles the conditional GET, byte range serving, and such. The hyper-0.11.x branch is async. You're most welcome to use them if you find them helpful; and if you don't find them helpful, I'd like to fix that.

My crate's young. There's no continuous build yet; the docs haven't gotten much attention; the APIs aren't stable yet; and I'm not in love with the current names http-entity and http-file. On the bright side, that means it's a good time if you have strong opinions on these things. Some possible upcoming API changes:

• the type of a given Entity's body stream and chunk type could become associate types rather than the current generics.
• http_entity::serve could become a trait method rather than its current free function. My habit is pure interfaces from languages such as Go, but it seems a lot of Rust stuff such as futures puts a lot of functionality in trait methods that the implementer doesn't need to override.
• http_file::ChunkedReadFile::new could move into a builder.