fix: add type safety to res.location to prevent encodeUrl crash
res.location() currently passes the value directly into encodeUrl(url).
If url is not a string (e.g., null, undefined, numbers, objects), this
causes a TypeError and crashes the response.
This PR adds a small input guard that normalizes the value using
String(url ?? ''), ensuring encodeUrl always receives a valid string
and preventing runtime crashes.
This is a code-only, backward-compatible safety improvement.
Hi maintainers 👋
This PR adds a small safety improvement to res.location() to prevent encodeUrl() from throwing on non-string input.
Happy to update anything if needed. Thanks for reviewing!
So now invalid inputs will be quietly ignored without a trace? That doesn't sound like a good idea. While I understand that getting errors is annoying, it is much easier to debug problems if they are clearly signalled.
So now invalid inputs will be quietly ignored without a trace? That doesn't sound like a good idea. While I understand that getting errors is annoying, it is much easier to debug problems if they are clearly signalled.
Thanks for the feedback! You're right — silently coercing invalid values
could hide mistakes and make debugging harder. I updated the PR to throw
a descriptive TypeError instead when res.location() receives a
non-string value. This makes the behavior explicit and avoids unexpected
silent failures.
Happy to adjust further if needed!
Thanks for the feedback — the previous version was too strict and didn't
match existing Express behavior. I've updated res.location() to:
- accept URL instances,
- coerce all non-string inputs using String(),
- avoid silent ignoring of invalid values,
- and maintain backward compatibility.
This now aligns with the expectations in test/res.location.js.