skip to content

In Postman, why does every operation on the jar from pm.cookies.jar() take a URL argument?

level: middleimportance: should knowfreq 40%

answer

  1. Not a flat map of names
  2. One run can hold the same name twice
  3. The URL selects which entries you mean
  4. Even clear is scoped, not a reset

basics

~20 s

Because the jar files entries against the URL they belong to rather than keeping a flat map of names. A name alone is ambiguous, so get, getAll, set, unset and clear each need the URL that selects them.

solid answer

~40 s

The store is keyed by URL, not by cookie name. One run can hold a `sid` for several hosts at once, so a bare name identifies nothing — every call has to say which URL it is asking about. `getAll(url, cb)` returns the entries that URL selects, `get(url, name, cb)` disambiguates by URL, `set(url, ...)` files the new entry as though it had arrived from that URL, and `clear(url, cb)` wipes only what that URL selects, never the whole store. The commonest bug follows directly: writing against one URL and reading against a different host or path returns nothing, and the store is blamed for a mismatch the caller introduced. Build the URL from the same value the request uses.

code

javascript · 11 lines
javascript
const jar = pm.cookies.jar();

jar.set('https://api.example.com/v1', 'sid', 'abc123', function () {
    jar.getAll('https://api.example.com/v1', function (err, cookies) {
        console.log('same url:', cookies.length);
    });

    jar.getAll('https://other.example.com', function (err, cookies) {
        console.log('other host:', cookies.length);
    });
});

go deeper

for a junior

Remember the call shape: the URL always comes first, then the cookie name where one is needed, then a callback. Copy the URL from the request rather than retyping a host into the script.

for a middle

Explain why the argument exists at all: entries are filed per URL, so one run can hold the same cookie name for several hosts and a bare name would be ambiguous on both reads and writes.

for a senior

Diagnose the classic empty-read: prove whether the URL selects nothing or the write never landed, and know that per-URL clearing means run isolation has to be arranged deliberately rather than assumed.

for a principal

Own how a shared harness constructs these URLs. A convention that derives them from the request under test removes a whole class of silent, environment-specific test failures across every collection a team maintains.

## The jar is keyed by URL, not by name The store behind `pm.cookies.jar()` is not a dictionary of cookie names. Each entry is filed against the origin it belongs to, and the only way to point at an entry is to say **which URL you are asking about**. That is why `get`, `getAll`, `set`, `unset` and `clear` all take a URL as their first argument: without it, a name like `sid` identifies nothing in particular, because a run can hold a `sid` for several different hosts at once. The jar does not invent the matching rules — the question of *which* URLs an entry travels to is the HTTP cookie subject, and the jar simply applies it. What the jar owns is the shape of the call: you always supply the URL, and the answer you get back is scoped to it. ## What the URL decides, per call | Call | The URL decides… | |---|---| | `getAll(url, cb)` | which entries come back — the set a request to that URL would carry | | `get(url, name, cb)` | which of the possibly several entries with that name you meant | | `set(url, name, value, cb)` | where the new entry is filed — it is stored as though it arrived from that URL | | `unset(url, name, cb)` | which single entry is removed | | `clear(url, cb)` | how much is wiped — everything that URL selects, and nothing beyond it | ## A worked failure A script writes a cookie against `https://api.example.com/v1` and a later script reads it back against `https://example.com`. The read comes back empty, the assertion fails, and the obvious conclusion — "the jar dropped my cookie" — is wrong. The entry is still there; the second URL simply does not select it. The same shape of bug appears with a path: writing against a deep path and reading against the site root, or the reverse, are two different questions asked of the same store. The practical habit that avoids this: - Build the URL you pass from the **same** value the request uses, rather than retyping a host into the script. - When a read comes back empty, call `getAll` for that URL first — an empty list tells you the URL selects nothing, and a populated list that lacks your name tells you the write never happened. - Do not treat `clear` as a reset. Clearing one URL leaves everything the run collected for other hosts exactly where it was. ## Why this shape, and not a flat map Three consequences fall out of URL-keying, and interviewers usually want at least the first two: 1. **Two hosts can hold the same cookie name without colliding.** A run driving a login service and an API can hold a `token` for each; nothing merges them. 2. **A write has to declare where it belongs.** `set` is not "add a name and value" — it is "record this as though the response from *this* URL had sent it", which is what makes the entry eligible for later requests. 3. **There is no single call that empties the store.** Cleanup is per URL, so a teardown script that clears one host is not isolating the run. ## The asynchronous edge Every one of these calls hands its answer to a callback rather than returning it. A read placed on the line after a write, outside the write's callback, races it. Nest the calls, or drive them from one callback chain, and the sequence becomes deterministic.

  • A script writes a cookie and the next read comes back empty. How do you tell a bad URL from a failed write?
    Call `getAll` for the URL you read with. An empty list means that URL selects nothing, so the URL is wrong or too narrow. A populated list that simply lacks your name means the write went elsewhere or never happened. Check the write's callback error before anything else.
  • Is there a single call that empties the run's whole cookie store?
    No. `clear` takes a URL and removes only what that URL selects, so emptying a run's store means clearing each URL you have touched. Teardown code that clears one host leaves the rest of the run's state intact, which is a common source of leakage between iterations.

saying these in an interview costs you the question

  • Describes the jar as a name-to-value dictionary
  • Expects clear with one URL to reset everything
  • Reads with a host that differs from the write
  • Thinks two hosts cannot hold the same cookie name
  • Assumes set only needs a name and a value