Utility Helpers

lib/utils.js is the shared utility module behind request parsing, response metadata, content handling, proxy handling, and query-string processing. Its dependencies include content-type, etag, mime-types, proxy-addr, qs, and node:querystring.

The module exists to keep cross-cutting transformations outside the request and response objects themselves. The application turns settings into callable functions, the request object invokes the configured query parser, and the response object invokes the configured ETag generator.

Sources: lib/utils.js:16, lib/utils.js:17, lib/utils.js:18, lib/utils.js:19, lib/utils.js:21, lib/application.js:351-380, lib/request.js:230-240, lib/response.js:162-165

Core concepts

Shared dependencies

A shared dependency is an external module loaded by lib/utils.js for use by its helpers.

The imports establish these module variables, while the shown helper bodies demonstrate the etag and qs call sites.

Sources: lib/utils.js:16, lib/utils.js:17, lib/utils.js:18, lib/utils.js:19, lib/utils.js:21, lib/utils.js:249-257, lib/utils.js:267-271

Parsed request metadata

Parsed request metadata is the structured result returned by acceptParams from a semicolon-delimited string.

The result contains a value, a numeric quality, and a params object; a q key updates quality, while other keys are stored in params.

Sources: lib/utils.js:89-120

ETag generator

An ETag generator is a function that converts a response body into a buffer when necessary and passes that buffer to etag.

The helper returned by createETagGenerator accepts both a body and an encoding, preserving an existing buffer and using Buffer.from for other bodies.

Sources: lib/utils.js:249-257

Extended query parser

An extended query parser is a function that delegates parsing to qs.parse with prototype properties explicitly allowed.

The shown helper therefore centralizes one particular query-string parsing operation; the supplied excerpts do not show how it is registered in application settings.

Sources: lib/utils.js:267-271

How shared helpers serve requests and responses

The request and response modules consume different configured helpers. A request reads query parser fn; if no parser is configured, it returns an object created without a prototype, otherwise it parses the URL query and passes the result to that function.

A response reads etag fn before sending data. ETag generation is eligible only when the response does not already have an ETag header and the configured value is a function.

This division keeps the request and response objects focused on HTTP behavior while lib/utils.js owns reusable conversion and parsing logic. The application connects settings to those helpers when app.set receives etag, query parser, or trust proxy.

Sources: lib/request.js:230-240, lib/response.js:162-165, lib/application.js:351-380

How a response body becomes an ETag

The ETag path begins with the response’s configured function. When the response has a body length and ETag generation is enabled, the response calls the configured function with the body and encoding, then sets the resulting value as ETag when one is returned.

The utility generator normalizes the body first. Existing buffers pass through unchanged; other bodies are converted with Buffer.from(body, encoding). The resulting buffer is then passed to etag(buf, options).

The important distinction supported by the excerpts is that etag is the imported dependency and callable used to calculate the tag, while createETagGenerator is the adapter that normalizes the body and supplies options. The supplied code does not show a wetag symbol, setting, or implementation, so no additional code-backed difference between etag and wetag can be stated.

A manually supplied ETag is preserved because generation requires that the response not already have an ETag header. A response with no body does not receive an ETag in the shown tests.

Sources: lib/response.js:189-193, lib/utils.js:249-257, lib/utils.js:17, lib/response.js:162-165, test/res.send.js:455-483

How settings become callable functions

The application’s settings layer performs the conversion. Setting etag stores the value and also assigns compileETag(val) to etag fn; setting query parser assigns compileQueryParser(val) to query parser fn; setting trust proxy assigns compileTrust(val) to trust proxy fn.

The table reflects the setting-to-function assignments shown in app.set; the excerpts do not show the later consumer for trust proxy fn.

The excerpts show that compileTrust and compileQueryParser are imported from ./utils and invoked when settings change, but they do not include the compiler bodies or enumerate the accepted setting-value forms. Consequently, the grounded explanation is that each compiler turns the setting value into the corresponding callable configuration; the exact conversion rules are outside the supplied excerpts.

Sources: lib/application.js:351-380, lib/application.js:16-25, lib/application.js:363-372

How it connects

lib/application.js is the configuration boundary: it imports compileETag, compileQueryParser, and compileTrust, then refreshes derived function settings through app.set. For the surrounding application lifecycle, see App Configuration & Settings.

lib/request.js consumes query parser fn when exposing req.query, while lib/response.js consumes etag fn while sending a body. Read The Request Object and Response: Sending Data for those public surfaces.

The application itself is created with request and response prototypes that are exposed through app.request and app.response; those prototypes are where utility-backed behavior becomes part of Express’s HTTP API. See Express Overview for the package entry point.

Sources: lib/application.js:16-25, lib/application.js:351-380, lib/request.js:230-240, lib/response.js:162-165, lib/response.js:189-193, lib/express.js:36-65

Key takeaways

• lib/utils.js centralizes reusable parsing, conversion, and dependency-backed helpers.
• createETagGenerator normalizes a body to a buffer and delegates tag generation to etag.
• Responses use etag fn; requests use query parser fn.
• app.set derives callable settings through compileETag, compileQueryParser, and compileTrust.
• The supplied excerpts do not define wetag or the detailed accepted values for the compiler helpers.

Sources: lib/utils.js:16, lib/utils.js:17, lib/utils.js:89-120, lib/utils.js:249-257, lib/utils.js:267-271, lib/request.js:230-240, lib/response.js:162-165, lib/application.js:351-380, lib/application.js:16-25