Skip to main content
GoodFirstPicks
DashboardIssuesReposLeaderboard

GoodFirstPicks by Leaveitblank © 2026

CreatorRequest a RepoPrivacy PolicyTerms of Service
HTTP module does not allow sending all valid header values | GoodFirstPicks

HTTP module does not allow sending all valid header values

nodejs/node 6 comments 1mo ago
View on GitHub
mediumopenScope: somewhat clearSkill match: maybeTest focusedNode.jsJavaScript

Why this is a good first issue

Header validation needs updating to match spec while maintaining security.

AI Summary

The issue involves updating HTTP header value validation to align with current specs while ensuring no regression on security vulnerabilities. The fix requires modifying regex patterns in the HTTP module and updating tests. Main blocker is ensuring security isn't compromised, as noted by maintainer feedback.

Issue Description

Version

v25.5.0

Platform

Microsoft Windows NT 10.0.26200.0 x64

Subsystem

http

What steps will reproduce the bug?

const http = require("http");

// 0x01 is allowed per the Fetch spec (only 0x00, 0x0A, 0x0D are forbidden)
// https://fetch.spec.whatwg.org/#header-value
http.request({
  hostname: "localhost",
  port: 1,
  headers: { "X-Test": "\x01" }
}); // throws ERR_INVALID_CHAR

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior? Why is that the expected behavior?

Header value validation should be performed according to:

  • https://fetch.spec.whatwg.org/#header-value
  • https://httpwg.org/specs/rfc9110.html#fields.values

The latter gives a more restrictive ABNF, but per the change in https://github.com/httpwg/http-core/commit/f594c2f65becfff5cf505abdf493e7dcacf8ef00 relaxes the actual strict validation rules to

a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message. Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake of robustness when they appear within a safe context (e.g., an application-specific quoted string that will not be processed by any downstream HTTP parser).

What do you see instead?

ERR_INVALID_CHAR

Additional information

This also affects undici/fetch, and prevents the following web platform test from passing:

https://github.com/web-platform-tests/wpt/blob/master/fetch/api/headers/header-values.any.js

Browsers pass this; you can confirm with

<!DOCTYPE html>
<script>
const xhr = new XMLHttpRequest();
xhr.open("GET", "/");
xhr.setRequestHeader("X-Test", "\x01");
xhr.send();

fetch("/", { headers: { "X-Test": "\x01" } });
</script>

and seeing that the headers do get sent over the network.

It would be fine if this functionality was off-by-default, but was in place fo

GitHub Labels

http

Want to work on this?

Claim this issue to let others know you're working on it. You'll earn 10 points when you complete it!

Risk Flags

  • security implications
  • spec compliance
Loading labels...

Details

Points10 pts
Difficultymedium
Scopesomewhat clear
Skill Matchmaybe
Test Focusedyes