Inside the cookie jar

Cookies are the part of HTTP that everyone treats as an implementation detail right up until a login flow breaks and someone spends an afternoon staring at a Set-Cookie header trying to work out why the session isn't sticking. We wanted Nop to treat them as a first-class citizen instead of an afterthought bolted onto the header list — so 0.1.0 ships a proper cookie jar.

What it does

The jar is a per-project store of cookies, keyed by domain and path, that sits alongside your requests and environments. Three things feed it:

• Any Set-Cookie response header from a request you send.
• Any Set-Cookie seen on traffic through the capture proxy.
• You, directly — add, edit or delete a cookie by hand from the jar's grid.

On the way out, matching cookies are attached automatically to any request whose host and path line up, the same domain-matching rules a browser would apply. You never have to copy a session token out of a response and paste it into a header field again.

Building it in three phases

We shipped this in three passes rather than one big-bang change, which turned out to matter more than we expected for a feature that touches both the data model and two different send paths.

Phase 1 was the boring, load-bearing part: the data model, CRUD operations, and serialization so a jar survives an app restart. Get this wrong and everything built on top of it inherits the bug.

Phase 2 wired cookie injection into the actual send paths — both the direct-request sender and the capture-proxy's forwarding path, which turned out to have subtly different header-assembly code and needed the matching logic applied twice, carefully, so neither path could silently skip it.

Phase 3 was the UI: a grid view of every cookie in the jar, a detail panel for editing one, and a switcher in the sidebar so the jar sits next to Collections and Environments instead of being buried in a settings screen.

Why it's worth the screen space

A cookie jar isn't glamorous, but it's the difference between "log in once and everything just works" and re-authenticating by hand every time you open a new request. For anyone testing session-based APIs — which is most APIs that aren't pure token auth — that's the gap between Nop being a curl replacement and being a workspace you actually live in.