Fix: Add type validation for sendStatus to prevent BigInt serialization error (#6756)
Fixes #6756
This PR adds type validation to res.sendStatus() to prevent uncaught TypeError when BigInt values are passed as status codes.
Problem:
-
res.sendStatus(200n)caused uncaught"Do not know how to serialize a BigInt"error - Error occurred when
sendStatus()calledthis.status()which internally usesJSON.stringify()
Solution:
- Add type checking at the beginning of
sendStatus()method - Throw consistent
TypeError: Invalid status codefor non-number inputs - Matches existing error handling patterns in Express
Changes:
- Add type validation in
lib/response.js - Add test case for BigInt input in
test/res.sendStatus.js - All existing tests pass (1239 passing)
- Follows existing error message format
- No linting errors
Testing:
npm test # All 1239 tests pass
npm run lint # No errors
@bjohansebas I've created the deprecation warning PR as requested. I kept it targeting master since that shows my actual 2-file changes cleanly. When I tried changing the target to 5.x it showed 36 changes (difference between branches).
Should I leave it targeting master and you'll handle getting it into Express v5, or would you prefer a different approach for the branch targeting?
The deprecation warning PR is ready for review - it adds the deprecate() call for non-number values in sendStatus().
This looks good, although this will be released for version 6 since it would be a breaking change, and we should first release a warning in version 5. Could you create a new PR to add a deprecation message?
I don't think that it would be a breaking change - 5.x already includes validation that was added in #4212. This probably could be documented better, because it's mentioned only for res.status (both in migration guide and History.md), but the same PR modified res.sendStatus to use res.status in order to benefit from this new validation.
The problem with serialization occurs during creation of the validation error message (see https://github.com/expressjs/express/issues/6756#issuecomment-3412660339).
Also it's not an uncaught exception, we expect a throw for invalid status and it will be handled.
The enhancement would be the error message change, which makes this a very low prio change IMO.
@jonchurch @wesleytodd I've updated the PR to address the feedback. I moved the validation logic entirely to res.status, and res.sendStatus now calls that internally, so there are no duplicate checks. I used typeof for the validation because standard string conversion turns 200n into "200", which makes the error message really confusing ("Invalid status code: 200"). By catching it early, we can show the actual issue ("Invalid status code: 200 (bigint)").. As a side effect of using typeof, all invalid inputs (strings, null, objects) are now including their type in the error message (e.g., 200 (string) or null (object)). All test cases are passing