Three copies of the same HTTP code, and how one Go engine fixed it

Kunal — Thu, 12 Nov 2026 02:36:17 +0000

A free API client for REST, GraphQL, gRPC and WebSocket, and what building it taught me about SSRF, sandboxing other people's JavaScript, and keeping secrets away from AI agents.

It started with a login screen.

I wanted to send one request to my own API, running on localhost, on my own machine. The API client I'd used for years asked me to sign in first. Then it wanted to sync my workspace. Then a banner told me that running a collection against a CSV file was a paid feature.

I wasn't even angry, I was curious. How hard can an API client be?

That was April 2025. The answer turned out to be "a lot harder than it looks", and also way more fun than I expected. The weekend project became Gostman, a free and open source (MIT) API client for REST, GraphQL, gRPC and WebSocket. It runs as a desktop app, in the browser and as a CLI, and there's no account, no telemetry in the app and no paid tier.

This isn't a feature tour. It's the engineering story: one decision I got wrong, the rewrite that fixed it, and three problems that looked small and really weren't.

If you only read one paragraph, read this one. Every request, from every surface (desktop, browser, CI, an AI agent), goes through one Go function. A small Policy value carries what's different about each environment. The public web proxy checks the IP it actually connects to, which closes the DNS rebinding hole that URL checks leave open. Scripts from imported collections run in the CLI inside a pure-Go JavaScript engine with time and memory limits. And secrets get matched by their value, including their common encodings, and replaced before anything reaches an AI agent.

So yeah, why Go?

An API client is mostly networking. Timeouts, redirects, TLS, proxies, cookies, cancellation, streaming. Go's standard library already has all of it, net/http, crypto/tls, context, a cookie jar, and none of it is magic.

I also wanted gostman run to work in any CI pipeline without telling people to install Node.js first. Go gives you one static binary. Build it, copy it, done.

For the desktop app I picked Wails. The backend is Go, the UI is React, and you don't ship a whole Chromium like Electron does. What I didn't appreciate at the time is that this meant the same Go code could sit behind a native window and behind a serverless function. That ended up being the entire story.

THE ARCHITECTURE:

Four ways in, one way out. The desktop app, the browser, a CI job and a coding agent all end up in the same function. It definitely didn't start like this though.

Phase 1: A desktop app that sends requests

Version one was pretty much what you'd guess. A Wails app with React on top. The UI builds a request object and hands it to Go, Go makes the HTTP call and sends back status, headers, body and timing.

Everything was saved locally on your machine, no database and nothing in the cloud. (Much later, collections became plain YAML files in a folder, so you can commit them next to your code.)

It worked, it was fast, and I was happy with it. Then people started asking for a version they could try without installing anything.

Phase 2: The browser version, and my biggest mistake

Which is fair. I wouldn't install a random app from a stranger on Reddit either.

So I built a web version. A browser can't call any API you type in because of CORS, so requests from the web app go through a small Go proxy function on Vercel.

This is where I messed up. The web frontend got its own JavaScript copy of the request preparation: variable substitution, query params, GraphQL bodies, auth headers, curl parsing. And the Go code that actually sent the request now existed twice too, once in the desktop backend and once in the Vercel proxy. Three copies of "basically the same code".

It was not basically the same code.

Copies of the same logic don't stay the same for long. Mine drifted slowly and quietly, and then all at once.

Binary responses (images, PDFs, anything that isn't text) came back corrupted, because both Go copies did string(bodyBytes) on the response and handed the UI mangled text.

Big integers changed value on the way out. Variables and GraphQL variables were decoded into floats, JSON.parse on the JavaScript side and json.Unmarshal into map[string]any on the Go side, and a 64-bit float can't hold every integer above 2^53. So a database ID like 9007199254740993 got sent as 9007199254740992. A different ID, with no error anywhere. That one was really fun to track down.

And cookies set during a redirect just vanished. Neither copy had a cookie jar, so a Set-Cookie on the first hop was never sent to the second.

Every bug I fixed in one copy was still sitting in another one. I was maintaining three API clients and telling myself it was one.

Phase 3: One engine

The fix was boring on purpose. There is now exactly one piece of code that builds and sends a request, a Go package called engine/, and from the outside it's one function:

func Send(ctx context.Context, r Request, policy Policy) Response

The desktop app calls it through a Wails binding. The Vercel proxy now just calls it too, and the JavaScript copy is gone. When the CLI and the MCP server came along, they called it as well. Nothing else builds its own http.Request.

All the hard stuff lives behind that function: variable substitution, a dozen auth schemes (Basic, Bearer, OAuth 2 with PKCE, AWS SigV4, Digest, NTLM, Hawk and more), body encoding, redirects, the cookie jar, proxies and client certificates.

The Policy struct

The obvious question: if the desktop app and a public web proxy run the same code, how does the desktop app still reach localhost:3000 while the public proxy refuses to?

Everything that's different between environments goes into one value:

type Policy struct {
    BlockPrivate      bool
    MaxResponseBytes  int64
    MaxTimeout        time.Duration
    Permit            func(host string) bool
    RevealSecrets     bool
    MaxStreamDuration time.Duration
    RunCommands       bool
    RawSockets        bool
    ...
}

The desktop app passes a relaxed one. The hosted proxy passes this:

var Policy = engine.Policy{
    BlockPrivate:      true,
    RecordBody:        true,
    MaxResponseBytes:  3 << 20,
    MaxTimeout:        30 * time.Second,
    MaxStreamDuration: 60 * time.Second,
    MinStreamRetry:    time.Second,
}

The engine never asks "am I running on a server right now?". It asks the policy. Supporting a new place to run means writing a new Policy, not adding if isWeb checks all over a package of nearly 9,000 lines.

Why it works

The big one for me: if a request passes in the desktop app, gostman run in CI builds and sends it the same way. Only the limits differ, and those are explicit in the policy. "Works in the GUI, fails in the pipeline" just stopped happening. Bugs get fixed once too. The binary body bug became "keep bytes as bytes and base64 them for the UI". The big number bug became decoder.UseNumber(), which keeps the digits as text. And new front ends got cheap. The CLI and the MCP server were mostly wiring, because the hard part was already there.

Phase 4: Putting a proxy on the internet (the SSRF problem)

Here's the scary part. The web proxy fetches whatever URL a stranger sends it. Without care, anyone can ask my server to fetch http://169.254.169.254/ (the cloud metadata endpoint) or something on an internal network. That's SSRF, server-side request forgery.

The obvious fix is to parse the URL, resolve the hostname, check the IP is public, and then send the request. It looks right. It isn't.

DNS doesn't have to give you the same answer twice. A hostname can resolve to a perfectly normal public IP while you check it, and to 127.0.0.1 a few milliseconds later when the HTTP client actually connects. That's DNS rebinding, and the check-then-connect approach walks right into it.

So the check moved into the dialer. The IP you check is the IP you connect to, with no second lookup in between (slightly simplified):

func guardedDial(ctx context.Context, network, address, family string) (net.Conn, error) {
    host, port, err := net.SplitHostPort(address)
    if err != nil {
        return nil, err
    }
    addresses, err := net.DefaultResolver.LookupIPAddr(ctx, host)
    if err != nil {
        return nil, err
    }
    for _, candidate := range addresses {
        if isBlockedIP(candidate.IP) {
            return nil, errBlockedAddress
        }
    }
    for _, candidate := range addresses {
        conn, err := dialer.DialContext(ctx, network, net.JoinHostPort(candidate.IP.String(), port))
        if err == nil {
            return conn, nil
        }
    }
    ...
}

Two details turned out to matter a lot more than I expected.

First, refuse the host if any of its addresses is blocked, not just the first one. Otherwise a record with one public and one private address gets through the moment the client falls back to the second one.

Second, the standard library checks are a good start but not enough. An address is blocked if it's not IsGlobalUnicast() (that catches loopback and link-local, including the 169.254.169.254 metadata endpoint) or if it's IsPrivate(). That still misses carrier-grade NAT (100.64.0.0/10), the benchmarking range (198.18.0.0/15), NAT64 (64:ff9b::/96), 6to4 (2002::/16), IPv4-translated IPv6 (::ffff:0:0:0/96) and a handful of reserved ranges. Several of those are ways to reach an internal IPv4 address through something that doesn't look like one. So there are 22 extra ranges on top. (Plain IPv4-mapped addresses like ::ffff:127.0.0.1 are already handled, because Go normalises them to 4 bytes before those checks run.)

This guard is a policy switch, not a law of nature. It's on in the hosted proxy, and off by default on the desktop, where reaching localhost is the whole point. Because it lives in the engine's dialer, it covers every request the proxy makes: HTTP, GraphQL, SSE, gRPC, calls to MCP servers, and every redirect hop too. (WebSockets in the web app connect straight from your browser, so there's no server in the middle to protect.)

Phase 5: The CLI, and running a stranger's JavaScript

Once the engine existed, gostman run was the obvious next step. It runs a whole collection in CI, writes JUnit or HTML reports, and exits non-zero when a check fails.

People coming from Postman expect pre-request and post-response scripts with test() and expect(). In the apps, those run in a Web Worker. In the CLI I really didn't want "install Node.js" to be a setup step, so scripts run in goja, a JavaScript engine written in pure Go. The CLI embeds (//go:embed) a bundle built from the same JavaScript modules the apps run, so the test()/expect() helpers exist once. Same lesson as Phase 2: one copy, so nothing can drift.

The catch is that scripts come from imported collections, which means from strangers. And strangers write things like

while (true) {}

or my personal favourite

const a = []; for (;;) a.push(a)

Neither one is allowed to hang your CI job or eat your laptop's memory.

goja can stop a running script with vm.Interrupt(), so every script runs under a watchdog with two limits:

func watch(vm *goja.Runtime, limit time.Duration) *watchdog {
    guard := &watchdog{vm: vm, ticker: time.NewTicker(memoryInterval), done: make(chan struct{})}
    guard.timer = time.AfterFunc(limit, func() { guard.interrupt(errExpired) })
    ceiling := heapInUse() + memoryAllowance
    go guard.audit(ceiling)
    return guard
}

Time is the easy one, time.AfterFunc interrupts the VM when it runs out. Memory is a compromise. goja can't tell you how much one runtime has allocated, so a goroutine reads the process heap from runtime/metrics every 50 ms and interrupts the script if the heap is more than 512 MB above where it was when the script started.

To be honest about it: this is a tripwire, not an isolation boundary. It measures the whole process, so a parallel run's allocations count too, and one huge allocation can land between two samples. A subprocess with OS limits would be stricter, but it would break the single-binary story. For runaway loops like a.push(a) it does exactly what I need. It turns "the CI runner got OOM-killed and nobody knows why" into "script exceeded its memory allowance", and I'll take that trade.

Phase 6: Letting AI agents in without leaking your keys

This is the bit I'm most excited about.

gostman mcp serves a collection over the Model Context Protocol, so Claude Code, Codex or Cursor can call your saved requests. You can say "hit the staging login endpoint and check the response shape" and it just does it.

The problem is that responses, error messages and request timelines are full of secrets. Anything that reaches the agent can end up in a model's context, and I didn't want anyone having to explain why the AI saw their production API key.

My first attempt redacted by name: hide the Authorization header, hide fields called password. That broke constantly. Tokens show up in query strings, inside JSON bodies, in error messages that echo the URL back, and base64-encoded inside a Basic auth header.

So the matching works on values instead. Names still decide what gets learned, like environment variables, secret-manager references (Vault, AWS, Azure, Google Cloud, 1Password, Bitwarden, KeePassXC) and auth fields. But what gets matched in the output is the actual value, plus the common forms it takes once encoded:

func variants(value string, shortest int) []string {
    candidates := []string{value}
    candidates = append(candidates, percentEncoded(value)...)
    candidates = append(candidates, jsonEscaped(value)...)
    candidates = append(candidates, base64Encoded(value)...)
    ...
}

That's percent-encoding, a few JSON-escaped forms, and base64 at all three byte alignments, which is what catches a password buried inside a Basic auth header. Then any text on its way out, whether it's a response body, a header, a timeline entry or an error, has every known form swapped for a marker like {{apiKey}}. Overlapping matches get merged so a token sitting inside a longer token can't leave half of itself visible.

The agent sees that {{apiKey}} was used and that the request came back 200, and it never sees a value Gostman knows about. The limit is just as clear: it can't redact something it never learned, or a value that's been transformed into something else, like an HMAC signature.

The thing nobody warned me about: Go versions

The Wails v2 CLI can't load packages on Go 1.25 or newer. So the whole module is pinned to Go 1.24.5, and that one constraint spread. goja is pinned to the last commit that still builds on 1.24. The official MCP Go SDK needs 1.25, so the mcp/ package is a small MCP implementation I wrote myself.

Writing my own MCP server felt like a step backwards at first. But Gostman only needs a small part of the protocol (stdio by default, Streamable HTTP on loopback with a bearer token if you want it), and the small surface made it easy to keep every tool result and error flowing through one place in the tool layer, which is where the redactor sits.

What I'd tell myself in April 2025

Put the differences between environments in a value, not in if statements. The Policy struct is the only reason this didn't turn into four engines.

Check security at the point where the connection actually happens. Checking a URL and checking a socket are not the same thing.

Copies of the same logic will drift. Not "might". Will.

And figure out your toolchain constraints early. One GUI framework's Go version ended up shaping three other dependencies.

Try it

Gostman is free and open source, and a solid Postman alternative if you don't want an account. Data-driven runs, load testing, a mock server, a gRPC client with a GUI, secret managers and the MCP server are all in the free version.

Source code (MIT): github.com/kunalgoesbyken/gostman

Test an API online with no sign-up: gostman.com/web

If you've built something like this, especially an SSRF guard or a script sandbox, I'd love to hear how you approached it. And if you try Gostman and something's missing, open an issue, I read all of them.

I built a free, open-source Postman alternative in Go: no account, collections are just YAML files

Kunal — Mon, 26 Oct 2026 17:09:13 +0000

I got tired of API clients that want an account before I can send a single request, so I built Gostman: a free, MIT-licensed API client for REST, GraphQL, gRPC and WebSocket. It runs as a desktop app, in the browser, and as a CLI.

Web app (no install, no account): https://gostman.com/web
Source: https://github.com/kunalgoesbyken/gostman

What it does

Protocols: REST, GraphQL (with a schema browser), gRPC (reflection or .proto files), WebSocket, Socket.IO, MQTT over WebSocket, Server-Sent Events, SOAP and MCP servers.
Auth: Basic, Bearer, API key, OAuth 2.0 with PKCE, OAuth 1, Digest, AWS SigV4, NTLM, JWT Bearer and more.
Collections are plain YAML in a folder, so they diff and review in Git like any other code. The desktop app has a Git panel.
Testing: assertions, pre-request and post-response scripts, and a collection runner with CSV or JSON data files.
CI: gostman run exits non-zero on failure and writes text, JSON, JUnit and HTML reports.
Extras: load testing (gostman load), a secret scanner (gostman scan), a mock server, traffic capture and OpenAPI import.
Secrets: OS keychain, HashiCorp Vault, AWS, Azure, Google Cloud, 1Password, Bitwarden and KeePassXC.
Import: Postman, OpenAPI, Insomnia, HAR, Bruno, .http files and curl.
Code generation for 13 languages, including cURL, Python, Go and Rust.

Using it with coding agents

I use coding agents every day, and the awkward part is handing them API credentials. gostman mcp exposes a collection to agents like Claude Code, Codex or Cursor so they can call your requests without seeing your secrets.

Under the hood

The desktop app is built with Go and Wails. The CLI is a single binary, so you don't need Node.js:

go install github.com/kunalgoesbyken/gostman/cmd/gostman@latest

There are also builds for Windows, macOS and Linux (.deb, AppImage, AUR). They aren't code-signed yet, so SmartScreen or Gatekeeper will ask you to confirm on first run.

Limits worth knowing

The web version sends requests through a small relay, so it can't reach localhost or private networks. Use the desktop app for those. Responses over 3 MB are truncated in the web version.

Feedback welcome

It's early and I'm building it in the open. If something is missing from your workflow, or an import from Postman or Bruno doesn't work, open an issue: https://github.com/kunalgoesbyken/gostman/issues

If you try it, I'd like to hear which features you actually use.

DEV Community: Kunal