Remove allocations and repeated work performed for every request:
- reuse a per-connection updateOutgoingData closure and a shared
'finish' listener instead of binding two functions per request,
reaching resOnFinish through the connection state stored on the
response
- cache the ServerResponse options object per server (custom response
classes keep receiving a fresh object)
- check for Host, Expect, Content-Length and Transfer-Encoding by
scanning rawHeaders instead of materializing req.headers, which was
built (with per-name toLowerCase calls) for every request even when
the application never reads it
- cache the rendered status line per status code when the reason
phrase is the default, skipping its character validation
- cache the complete 'Date: ...' header line in the utcDate cache and
the keep-alive header pair for the current server settings
- compute the lenient-validation option chain once per message
Signed-off-by: Matteo Collina <hello@matteocollina.com>
PR-URL: https://github.com/nodejs/node/pull/65802
Reviewed-By: Robert Nagy <ronagy@icloud.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Gürgün Dayıoğlu <hey@gurgun.day>
Promote DEP0195 from documentation-only to a runtime deprecation.
Calling node:http constructors without `new` now emits DEP0195 via
deprecateInstantiation. This covers Agent, Server, OutgoingMessage,
IncomingMessage, ServerResponse, and ClientRequest.
Update in-tree tests that called Server/Agent without `new` to use
the keyword, and add a dedicated DEP0195 coverage test.
Refs: https://github.com/nodejs/node/pull/58518
Assisted-by: Grok
Signed-off-by: Yagiz Nizipli <yagiz@nizipli.com>
PR-URL: https://github.com/nodejs/node/pull/64853
Reviewed-By: Aviv Keller <me@aviv.sh>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Reviewed-By: Gürgün Dayıoğlu <hey@gurgun.day>
Reviewed-By: Filip Skokan <panva.ip@gmail.com>
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
IncomingMessage 'close' is emitted when request handling completes, not
only when the underlying connection is closed. Using that event to abort
IncomingMessage.signal makes the signal abort after a request body is
read normally.
Track the underlying socket close instead, and detach the listener when
the request or response completes normally. This keeps the signal from
being aborted by normal stream completion or later keep-alive socket
closure, while still aborting it when the connection closes during the
active request lifecycle.
Signed-off-by: Archkon <180910180+Archkon@users.noreply.github.com>
PR-URL: https://github.com/nodejs/node/pull/64392
Fixes: https://github.com/nodejs/node/issues/64390
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
Reviewed-By: Gürgün Dayıoğlu <hey@gurgun.day>
Add a new httpValidation option to http.createServer() and
http.request() / http.ClientRequest that controls how strictly
HTTP header values are validated:
- 'strict' - reject any non-ASCII or control characters (default)
- 'relaxed' - allow the non-ASCII characters permitted by the
Fetch specification (kLenientHeaderValueRelaxed)
- 'insecure' - disable all validation (like insecureHTTPParser)
The option is threaded through _storeHeader -> processHeader ->
storeHeader -> validateHeaderValue, and also through
writeInformation -> processInformationHeader -> validateHeaderValue.
Cannot be used together with insecureHTTPParser.
Fixes: https://github.com/nodejs/node/issues/61582
Signed-off-by: RajeshKumar11 <kakumanurajeshkumar@gmail.com>
PR-URL: https://github.com/nodejs/node/pull/61597
Refs: https://github.com/nodejs/node/issues/61582
Refs: https://fetch.spec.whatwg.org/#header-value
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Previously, socketOnDrain could be invoked synchronously from
_flushOutput (via _onPendingData -> updateOutgoingData) while the bytes
just handed to the socket were still buffered and while outputSize had
not yet been reset on the OutgoingMessage. The 'drain' event fired even
though res.writableLength was non-zero, breaking the invariant a user
would reasonably expect after `while (!res.write(...));`.
Gate the emission in socketOnDrain on msg.writableLength === 0 (which
also covers outputSize + chunked buffer + socket.writableLength), and
apply the same check in OutgoingMessage._flush so that 'drain' is only
emitted when the response is genuinely drained. The socket's own
'drain' event will otherwise propagate through socketOnDrain when the
socket buffer actually empties.
Signed-off-by: Robert Nagy <ronagy@icloud.com>
Assisted-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
PR-URL: https://github.com/nodejs/node/pull/62936
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
Reviewed-By: Gürgün Dayıoğlu <hey@gurgun.day>
Add validateHeaderName/validateHeaderValue checks for non-link
headers and checkInvalidHeaderChar for the Link value in HTTP/1.1
writeEarlyHints, closing a CRLF injection gap where header names
and values were concatenated into the raw response without
validation.
Also tighten linkValueRegExp to reject CR/LF inside the <...>
URL portion of Link header values.
PR-URL: https://github.com/nodejs/node/pull/61897
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Tim Perry <pimterry@gmail.com>
Previously, we ignored all indicators of the body (content-length or
transfer-encoding headers) and treated any information following
the headers as part of the upgraded stream. We now fully process the
requests bodies separately instead, allowing us to automatically handle
correct parsing of the body like any other HTTP request.
This is a breaking change if you are currently accepting HTTP Upgrade
requests with request bodies successfully, or if you use
socket-specific fields & methods on the upgraded stream argument.
In the former case, before now you will have received the request body
and then the upgraded data on the same stream without any distinction
or HTTP parsing applied. Now, you will need to separately read the
request body from the request (the 1st argument) and the upgraded
data from the upgrade stream (the 2nd argument). If you're not
interested in request bodies, you can continue to just read from the
upgrade stream directly.
In the latter case, if you want to access the raw socket, you should do
so via request.socket, instead of expecting the 2nd argument to be a
socket.
PR-URL: https://github.com/nodejs/node/pull/60016
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
Reviewed-By: Ethan Arrowood <ethan@arrowood.dev>
Reviewed-By: Rafael Gonzaga <rafael.nunu@hotmail.com>
Previously, you could either add no 'upgrade' event handler, in which
case all upgrades were ignored, or add an 'upgrade' handler and all
upgrade attempts would effectively succeed and skip normal request
handling. This change adds a new shouldUpgradeCallback option to HTTP
servers, which receives the request details and returns a boolean that
controls whether the request should be upgraded.
PR-URL: https://github.com/nodejs/node/pull/59824
Reviewed-By: Luigi Pinca <luigipinca@gmail.com>
writeHead accepts a raw header array, which is intended to allow
directly specifying raw header details, such as ordering, duplicates
and header key casing. When used by itself this works correctly.
However, if setHeader was called first, it effectively changed the
behaviour of subsequent writeHead calls, so that even if a raw header
array was provided, duplicates were collapsed, losing raw header data.
This change preserves the raw headers passed to writeHead, while still
maintaining the 'writeHead overwrites setHeader' behaviour.
PR-URL: https://github.com/nodejs/node/pull/50394
Reviewed-By: Matteo Collina <matteo.collina@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Sebastian Beltran