Response: Headers, Cookies & Redirects

This page covers the response helpers that attach metadata to an HTTP response: cookies, redirects, varying cache behavior, and appending header values. The response object is created from Node’s http.ServerResponse, so these helpers build on the server response rather than replacing it.

The practical reason for these helpers is consistency: application code can express common response policies without manually formatting cookie strings or redirect headers.

Sources: lib/response.js:43

Core concepts

Response object

The response object is Express’s res, created with Node’s http.ServerResponse.prototype as its prototype.

Sources: lib/response.js:43

Set-Cookie

A Set-Cookie entry is the response header used by res.cookie() and res.clearCookie() to send or expire a browser cookie. A simple cookie is emitted with a default Path=/.

Sources: test/res.cookie.js:23-35, test/res.clearCookie.js:7-18

Signed cookie

A signed cookie is a cookie requested with the signed option; the test suite verifies that an object cookie can be written and later read back through signed-cookie parsing.

Sources: test/req.signedCookies.js:14-32

Redirect location

A redirect communicates its destination through the Location header and defaults to HTTP status 302 in the tested form.

Sources: test/res.redirect.js:8-19

Vary policy

A Vary policy controls whether the response exposes a Vary header for a requested field set. Calling res.vary() without a field is an error, while passing an empty array leaves Vary unset.

Sources: test/res.vary.js:7-36

How cookies become response headers

res.cookie(name, value, options) turns application values and options into Set-Cookie output. The shown tests establish that a string value is serialized directly, special characters are encoded, and repeated calls produce multiple cookie values rather than replacing earlier calls.

The available source excerpts do not include the body of res.cookie(), so they do not show the exact internal sequence for serializing every option such as maxAge or applying the signature. What they do prove is the externally visible contract: cookie options are accepted, maxAge: null is omitted from output, and signed: true supports a signed object cookie round trip.

The sequence captures the tested boundary: a handler calls res.cookie(), the response exposes Set-Cookie output, and the HTTP test checks that output.

Sources: test/res.cookie.js:37-50, test/res.cookie.js:128-156, test/req.signedCookies.js:14-32, test/res.cookie.js:23-35

How cookies are cleared

res.clearCookie(name) expires a named cookie by sending an empty value with an expiration date of Thu, 01 Jan 1970 00:00:00 GMT.

This is deliberately a response-header operation: the test does not show server-side deletion of a stored session or any other data. In the acceptance flow, the client first receives a cookie, sends it to a forget endpoint, and then expects a clearing cookie whose value begins with remember=;.

Sources: test/res.clearCookie.js:7-18, test/acceptance/cookies.js:36-51

How redirects and header accumulation behave

res.redirect() sets a Location header and, in the tested default form, returns status 302. An absolute URL is preserved as the destination, while a relative application path is also used as a Location value in the authentication acceptance test.

The shown tests do not include a call to res.redirect('back'), nor do they show the implementation branch that would resolve that special value. Therefore this source pack proves relative paths such as /login and /, but it does not establish what back does in this version.

Redirect URLs are encoded before being exposed in the Location header: the tested snowman and section-sign characters become percent-encoded output.

res.vary() requires a field argument in the tested API: no argument produces a 500 response matching a “field required” error, while an empty array produces no Vary header.

The provided excerpts do not include the res.vary() implementation or the res.append() implementation, so they cannot prove the precise deduplication or merge algorithm for existing headers. The available tests do establish the non-overwriting behavior relevant to cookies: repeated cookie calls preserve multiple values, and the append helper has a dedicated test that checks header value count and order.

Sources: test/res.redirect.js:8-19, test/acceptance/auth.js:65-79, test/res.redirect.js:22-32, test/res.vary.js:7-36, test/res.cookie.js:37-50, test/res.append.js:107-116

How it connects

The response helpers sit on the response object used by route and middleware handlers; the acceptance tests show handlers calling response methods and clients following the resulting Location or Set-Cookie headers.

The response module also imports encodeUrl, path, and http, indicating that URL encoding, path operations, and Node’s HTTP response primitives are part of the broader response implementation.

For the wider request/response model, continue with The Request Object and Response: Sending Data. For routing and the handlers that invoke these helpers, see App Routing & Request Dispatch.

Sources: test/acceptance/cookies.js:36-51, lib/response.js:18, lib/response.js:20, lib/response.js:23

Key takeaways

• res.cookie() emits Set-Cookie output with a default Path=/, preserves repeated calls, and accepts options without mutating the caller’s object.
• maxAge: null is omitted from the tested cookie output, while signed: true supports a signed object-cookie round trip.
• res.clearCookie() expires a cookie using an empty value and a 1970 expiration date.
• res.redirect() produces a 302 Location response in the tested default form and encodes special URL characters.
• The pack proves relative redirect paths and Vary validation, but does not show the implementation of back resolution or the exact header merge algorithms.

Sources: test/res.cookie.js:128-156, test/req.signedCookies.js:14-32, test/res.clearCookie.js:7-18, test/acceptance/auth.js:65-79, test/res.vary.js:7-36