skip to content

In Postman, where do the cookies in pm.cookies come from after a request that redirected?

level: seniorimportance: should knowfreq 35%

answer

  1. It is a store read, not a parse
  2. Which URL gets queried matters
  3. The chain's last stop is the one
  4. Entries carry no record of who wrote them

basics

~20 s

Out of the run's cookie jar, read against the final URL the exchange ended on. The list is never parsed from the response's Set-Cookie headers, so it can omit something a hop sent and include something this exchange never sent.

solid answer

~50 s

`pm.cookies` is a **jar read**, not a header parse. After a redirect chain the run queries its one store using the final URL, and hands the script whatever that URL selects. Two consequences follow. A cookie a hop asked to store may be absent, because the final URL does not select it or the jar declined to store it. And a cookie this exchange never sent may be present, because an earlier request, a script write, or a jar read in at start-up put it there — the list carries no notion of who wrote an entry. If a test must prove that a specific response issued a specific cookie, look at that response's own header list; if it must prove the run is now carrying a session, `pm.cookies` is the right place to look.

code

javascript · 5 lines
javascript
console.log(pm.cookies.has('sid'));

pm.cookies.jar().getAll('https://api.example.com/v1', function (err, cookies) {
    console.log(cookies.map(function (c) { return c.name; }));
});

go deeper

for a junior

Remember that pm.cookies is read out of the run's store, not out of the response you just received, and that after a redirect the URL used for that read is the one the exchange finished at.

for a middle

Explain both surprises this creates: a cookie the exchange sent can be missing because the final URL does not select it, and a cookie it never sent can appear because something earlier in the run stored it.

for a senior

Show the diagnostic split. Decide whether the defect is the server not sending, the store not holding, or the query URL not selecting, and pick the right evidence for each rather than re-running and hoping.

for a principal

Own the assertion policy. Decide which tests are allowed to assert on carried state at all, since assertions on a shared store pass for the wrong reason and quietly hide broken authentication for a long time.

## `pm.cookies` is a jar read, not a header parse The most common mental model of `pm.cookies` — "the cookies this response set" — is wrong, and a redirect chain is where the difference finally shows. The list is built by **reading the run's cookie jar**, and the URL it reads against is the **final** URL the exchange ended on. Nothing about it is derived from parsing the response's own header list. Two independent things are therefore happening after a request that redirected: - the run followed the chain and stored, in the one jar, whatever each hop legitimately contributed; - the script's `pm.cookies` was then filled by asking that jar what it holds **for the URL the chain finished at**. The mechanics of a redirect — what gets re-sent, which credentials survive a hop — are the HTTP subject and not this store's business. All that matters here is which URL the jar was interrogated with afterwards. ## Three surprises this produces 1. **A cookie the response sent can be missing.** If a hop set a cookie that the final URL does not select, the jar may well hold it, but `pm.cookies` — asked about the final URL — will not show it. 2. **A cookie this response never sent can be present.** An entry written by an earlier request in the same run, by a script, or read in from a serialised jar at start-up, appears in the list on equal terms with anything this exchange contributed. The list has no notion of "who put this here". 3. **A cookie the jar refused is missing even though the header was there.** The header arriving is not the same event as the entry being stored, and only stored entries are visible. ## Header versus jar, side by side | Question | Where the answer lives | |---|---| | What did *this* exchange ask the client to store? | the response's own header list | | What does the run currently hold for this URL? | `pm.cookies` | | What does the run hold for some *other* URL? | `pm.cookies.jar().getAll(url, cb)` | | What will the next request to that URL carry? | the jar, again — via `getAll` | ## Debugging with the distinction When an assertion on `pm.cookies` fails, the useful first move is to decide which of the two layers broke: - Look at the response's header list. If nothing asked for the cookie, the defect is on the server side and the jar is behaving correctly. - If the header is there but the entry is not, the exchange ended somewhere the entry does not apply to, or the jar declined to store it. - Ask the jar directly with `getAll` for a URL you choose. That takes the "final URL" variable out of the picture: you are now querying the store on your own terms rather than through whatever the run happened to land on. ## Why the design is the right one Reading out of the jar keeps one source of truth. If `pm.cookies` were parsed off headers, a script would see something the run is not actually going to send — a list that agrees with the wire but disagrees with the store that drives the next request. By reading the store, the list always answers the question that matters for the rest of the run: **what will the next request to this URL carry?** The cost of that design is exactly the surprise above: the list is not a transcript of the last exchange, and treating it as one produces assertions that pass for the wrong reason. A test that must prove a specific response issued a specific cookie has to look at that response; a test that must prove the run is now carrying a session is right to look at the jar.

  • A test asserts on pm.cookies and passes, yet the endpoint under test never issued the cookie. How?
    The entry was already in the store. An earlier request in the same run, a script write, or a jar read in at start-up can put it there, and the list does not distinguish by origin. The assertion proved the run holds a cookie, not that this response issued one.
  • How would you prove a specific response issued a specific cookie?
    Inspect that response's own header list rather than the store. The jar answers what the run currently holds and what the next request will carry; only the response tells you what that exchange asked the client to store. The two questions need two different sources.

It is a stock check at one shelf after the delivery round, not a copy of the delivery notes.

saying these in an interview costs you the question

  • Says pm.cookies is parsed from Set-Cookie headers
  • Assumes the list reflects the originally requested URL
  • Treats the list as a transcript of the last exchange
  • Concludes the jar dropped a cookie it never selected
  • Uses the list to prove which response issued a cookie