Post · bonfire.cafe

@algernon@come-from.mad-scientist.club · 2 weeks ago

Today, my mind wandered off, and started thinking about a reverse proxy with first class support for #iocaine again.

This has been on my mind a lot lately, in various shapes and forms, especially since I redesigned #iocaine3's configuration, and it can spawn any number of server processes.

But I don't want to put this into iocaine itself, that'd pull in a lot of otherwise unnecessary dependencies. I could do without any, if I made it incredibly simple and limited, but... that doesn't feel right.

Today's train of thought led to an idea that I'd build it as a separate project, which would depend on iocaine, and use it as a library. It wouldn't communicate with an external iocaine like the traefik/haproxy/nginx/caddy/apache modules do (or will) - it would embed it.

algernon, the mad

@algernon@come-from.mad-scientist.club replied · 2 weeks ago

One of the major reasons I'm thinking about this is that I'm increasingly unhappy with Caddy, and would love to replace it with something else.

I'm unhappy with Caddy is because it eats an entire core on Eru, and half a gig of resident memory to boot. I don't think that's fine. I'm okay with it, for now, because my other options are worse in other ways:

As far as I'm able to tell, Apache doesn't have the hooks required to support iocaine's current model.
nginx is faster, uses less resources, but it's configuration language is all kinds of horrible. I'd rather use Caddy with lower performance and higher resource use, but a much saner config language.
I have little to no experience with traefik, but looking at their pricing page, they're all-in on AI shit. The configuration is YAML or TOML soup too... and, no thanks.

Besides, neither of them is in Rust, so embedding iocaine in either is not an option. I'd always have to pay the overhead of an external process, and some kind of IPC.

famfo

@famfo@frogs.lgbt replied · 2 weeks ago

@algernon traefik can be configured nicely via nix, the rest is a bit annoying. Afaik HAProxy can do the same as traefik but with slightly more C and footguns, haven't tried the amount of footguns thoroughly for everything that isn't HTTPS proxying

Daniel

@dan@axillae.telent.net replied · 2 weeks ago

@algernon I have no experience with haproxy but iirc it's configurable with lua, so ...

algernon, the mad

@algernon@come-from.mad-scientist.club replied · 2 weeks ago

So I'm thinking about what I need, those needs are - in my opinion - very modest.

HTTPS, with support for automatically obtaining certs from LetsEncrypt.
HTTP -> HTTPS redirect (optional, but enabled by default)
HTTP 1.x and HTTP2 for incoming traffic. Don't care much about HTTP3 at the moment.
Reverse proxying to other things, over TCP or UDS or AUDS sockets, using HTTP1.1. Don't care about HTTP2 or TLS or other protocols and transports here.
Ability to transform requests before sending them to the reverse proxy (path rewrites, headers, etc)
Ability to transform the response before sending them to the client.
Compression (zstd & gzip)
Static responses (not static files: static responses)

I don't need plugins, I don't need static file serving, I don't need container discovery, I don't need authentication, nor fastcgi, nor php, nor HTTP push, nor templates.

4censord :nfp:

@4censord@unfug.social replied · 2 weeks ago

@algernon hmm, have you considered haproxy?

algernon, the mad

@algernon@come-from.mad-scientist.club replied · 2 weeks ago

What I had in mind is a reverse proxy, built on top of iocaine, and extending its configuration.

Something like this:

acme {
// acme/LE configuration here
}

iocaine {
declare-handler nam-shub path=".../nam-shub-of-enki" {
inherits "default"
}
}

https-server main {
bind "0.0.0.0:443" http http2
use iocaine-handler=nam-shub
host "iocaine.madhouse-project.org" {
use middleware="iocaine.madhouse-project.org"
upstream "10.69.0.42:8096"
}

middleware "iocaine.madhouse-project.org" script-path="..." {
// middleware configuration
}
}

The "middleware" would be a Roto script with two functions: request_transform and response_transform. Requests & responses would be mutated by Roto, as the script sees fit.

The reason I'd use Roto here is that I'm doing a lot of rewrites and redirs, and I feel those would be easier to express in a programming language, rather than trying to do it declaratively in bespoke syntax.

My gut feeling is that using Roto here would also make it more efficient than evaluating expressions through something like CEL.

algernon, the mad

@algernon@come-from.mad-scientist.club replied · 2 weeks ago

The middleware? How about this:

fn request_transform(request: Request) -> Request? {
if request.path.starts_with("/documentation/stable") {
let path = request.path
.replace_prefix("/documentation/stable", "/documentation/2")
.strip_suffix("index.html");
return redirect_found(path)
}
if request.path.starts_with("/configuration/") {
return redirect_moved(f"/documentation/2{request.path}");
}
# and so on...

Some(request)
}

algernon, the mad

@algernon@come-from.mad-scientist.club replied · 2 weeks ago

Or:

fn request_transform(request: Request) -> Request? {
request
.replace_prefix("/documentation/stable", "/documentation/2)
.redirect(http.status.FOUND);
request
.move("/configuration/", "/documentation/2");

request
}

This would mutate things in-place.

algernon, the mad

@algernon@come-from.mad-scientist.club replied · 2 weeks ago

Except, of course, neither of these is correct! These generate responses.

1+ more replies (not shown)

Lars Wirzenius

@liw@toot.liw.fi replied · 2 weeks ago

@algernon I've already decided to not pursue writing my own web server. This includes a reverse proxy. Sorry.

bonfire.cafe

A space for Bonfire maintainers and contributors to communicate

bonfire.cafe: About · Code of conduct · Privacy · Users · Instances

Bonfire social · 1.0.0 no JS en

Automatic federation enabled