HTTP module does not allow sending all valid header values #61582
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_CHARHow 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:
The latter gives a more restrictive ABNF, but per the change in httpwg/http-core@f594c2f 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 for those wanting to write spec-compliant libraries (like jsdom).