Two traps in java.net.http.HttpClient that bite when you route it through a proxy, because neither one looks like a proxy problem at first.

Basic proxy auth is disabled for HTTPS tunnels by default, so your username and password can be perfectly right and the tunnel still fails on auth.

The nastier one: point it at a SOCKS proxy and it gets ignored, so requests leave from the machine's own address. No exception, no warning. Everything looks fine until you check the exit IP, and by then the job may have run for a week from your server.

So whatever client you use, I'd log the exit IP once at startup and fail the run if it matches the host's address. It's a few lines and it catches this whole family of mistakes.

Disclosure: we run a proxy service, this came out of comparing proxy support across languages.

Speed, on the full configs: 3.6–5.7x faster on one thread, up to 38x on 16, and 37–400 MB of memory instead of 3–4 GB. A single file takes about 10 ms, which is the number I actually cared about, because that’s what makes it usable in a pre-commit hook.

Another week, another update for @CloudNativeFdn#cloudnative #observability tracing for developers workshop! Featuring @opentelemetry, @jaegertracer, @Prometheus, @java, @Podman_io and @RancherDesktop! Start exploring #o11y on k3s today! @SUSE bit.ly/otel-java-dev-workshop