Http

Every few months I find myself stuck on the same kind of question: what exactly is hitting my service? A reverse proxy is mangling a header, a Kubernetes ingress is rewriting a path, a webhook provider is sending a body in some shape I didn’t expect. The fastest way to answer is to point the traffic at something that will tell me, in painful detail, what arrived.

That’s why I wrote http-echo: a tiny Go server that responds to any HTTP request by dumping a structured, human-readable report of everything it saw.

Once in a while I need to throw a directory online. Share a build artifact with a colleague, expose a folder of files inside a Kubernetes cluster, mount a release directory behind an internal nginx — the kind of task where a full web server is overkill and python3 -m http.server is too primitive.

That’s the niche httpfileserver fills: a single static Go binary (or a scratch-based Docker image) that serves a directory, with the few quality-of-life features I always end up wanting.

When a service starts misbehaving, my first reflex is ping. It tells me almost instantly whether the box is up, whether latency is sane, and whether anything weird is going on at the network layer. The trouble is that for HTTP services, ping answers the wrong question. The host can answer ICMP just fine while the application returns 502s every other second.

httping-go is my Go take on the classic httping idea: a tiny CLI that hits a URL on a loop and prints status code, latency and response size. It’s the tool I reach for when I want a quick, continuous feel for how an HTTP endpoint is behaving.