Ideas for new features

[apollo13]

Hi, I am currently looking into dumbproxy to replace a squid based setup with it. What I am currently missing (and wondering whether you'd be okay to add support for those):

• a health check endpoint to check if the proxy is up & running (might already exist but I can't find the URL :D)
• a way to reload the access filter without restarting the proxy
• a log output (maybe via structured logging) that provides one message with all the relevant data (that is who tried to access what and whether the request was allowed or denied).

What do you think about those, happy to elaborate if anything is unclear.

[Snawoot]

Hi!

• a health check endpoint to check if the proxy is up & running (might already exist but I can't find the URL :D)

There is an issue about that: #70

Key highlights from that thread:

• It's already possible to test proxy's handler somehow, but not with a typical /healthz request expecting 200 OK.
• Having /healthz endpoint available from outside makes an additional fingerprint signature which I really don't want to be there by default.
• If healthcheck endpoint is in the same HTTP server, it adds unnecessary complication distinguishing between direct requests to proxy service and requests meant to be forwarded. And, with authentication in the mix, healthcheck must be either processed as authorized request (complicates probing) or unauthorized (exposes to everyone, leaves signature).

Dumbproxy grew a lot since then, now it has many other modes of operation besides HTTP proxy:

• SOCKS5 mode
• stdio mode
• Single port forwarding mode

Obviously, integrating /healthz endpoint straight on main port doesn't make sense in these modes. The solution I see as reasonable is an optional separate HTTP port for healthchecks, just like we have for profiling endpoints. However, it defies the purpose of healthcheck to some degree because these healthchecks won't be even served from the same goroutine accepting connections as main program service.

• a way to reload the access filter without restarting the proxy

You can already do that to some degree, reloading and eval-ing some other script from file if some time has passed since last reload. dumbproxy JS runtime has eval and readFile functions and all standard ECMAScript objects such as Date. If something else is needed, we can extend runtime with new functions hooked to native Go functions. So far there was little need to do that, though.

But I think that touches a broader topic. Access filter is just a part of configuration and dumbproxy doesn't have a hot configuration reload. Fork and re-exec are not available on all platforms and there's no safe way to do that kind of reload with Go. What's remaining is to have shared synchronized configuration state, which encumbers all the code with a concurrent access to everything about its configuration.

I'd like to keep things simple, so I skipped all that struggle. And apparently it was a good choice: I was asked for hot reload just twice, including this time. And finally, in modern containerized environment even daemons with hot reload do not use that except for ingress controllers. The usual way to do things now is to drain old deployment pods and spawn new with the new configuration, even if daemon supports reload: https://kubernetes.io/docs/tutorials/services/pods-and-endpoint-termination-flow/

In any case, I'd like to learn more about what changes in your access rules. Maybe you can just get away with reloading dataset instead of reloading JS code. Or maybe we should just limit lifetime of each JS VM instance, so they'll pick up new code eventually.

• a log output (maybe via structured logging) that provides one message with all the relevant data (that is who tried to access what and whether the request was allowed or denied).

You can format (including JSON) and print any attributes of requests and outcome of your decision right from script with the print function. E.g., access filter

function access(req, dst, username) {
  print(`deny: ${JSON.stringify({reason: "not feeling like doing that", req: req, dst: dst, username: username})}`);
  throw newStopAddressIteration();
}

will produce log line

JSACCESS: 2026/01/22 15:13:25 printer.go:17: INFO     deny: {"reason":"not feeling like doing that","req":{"method":"CONNECT","url":"//google.com:443","proto":"HTTP/1.1","protoMajor":1,"protoMinor":1,"header":{},"contentLength":0,"transferEncoding":[],"host":"google.com:443","remoteAddr":"127.0.0.1:45982","requestURI":"google.com:443"},"dst":{"network":"tcp","originalHost":"google.com","resolvedHost":"142.250.109.102","port":443},"username":""}

BTW, project README serves as a complete reference for all available features, all built-in functions are covered there too: https://github.com/SenseUnit/dumbproxy?tab=readme-ov-file#scripting-functions

[apollo13]

Having /healthz endpoint available from outside makes an additional fingerprint signature which I really don't want to be there by default.

IC, I'll try the option variant.

You can already do that to some degree, reloading and eval-ing some other script from file if some time has passed since last reload.

Mhm interesting, that would indeed work -- probably more than I wanted to do in JS but probably okay.

In any case, I'd like to learn more about what changes in your access rules. Maybe you can just get away with reloading dataset instead of reloading JS code.

Yes I can get away with reloading the dataset.

You can format (including JSON) and print any attributes of requests and outcome of your decision right from script with the print function. E.g., access filter

Yeah that is certainly true, but that also increases the log noise quite a bit (that said, it is certainly a workable solution).

Thank you for your help, I'll see what I can come up with :)