Invalid header value check

[szmarczak]

Version

v16.6.0

Platform

Linux solus 5.13.6-190.current #1 SMP PREEMPT Fri Jul 30 17:08:12 UTC 2021 x86_64 GNU/Linux

Subsystem

http

What steps will reproduce the bug?

http.validateHeaderValue('location', '☃')

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

Always.

What is the expected behavior?

No error.

What do you see instead?

TypeError [ERR_INVALID_CHAR]: Invalid character in header content ["location"]
    at __node_internal_captureLargerStackTrace (node:internal/errors:464:5)
    at new NodeError (node:internal/errors:371:5)
    at Object.__node_internal_ [as validateHeaderValue] (node:_http_outgoing:567:11) {
  code: 'ERR_INVALID_CHAR'
}

Additional information

RFC2616:

       OCTET          = <any 8-bit sequence of data>
       CHAR           = <any US-ASCII character (octets 0 - 127)>
       CTL            = <any US-ASCII control character
                        (octets 0 - 31) and DEL (127)>
       CR             = <US-ASCII CR, carriage return (13)>
       LF             = <US-ASCII LF, linefeed (10)>
       SP             = <US-ASCII SP, space (32)>
       HT             = <US-ASCII HT, horizontal-tab (9)>
       CRLF           = CR LF
       LWS            = [CRLF] 1*( SP | HT )

       message-header = field-name ":" [ field-value ]
       field-name     = token
       field-value    = *( field-content | LWS )
       field-content  = <the OCTETs making up the field-value
                        and consisting of either *TEXT or combinations
                        of token, separators, and quoted-string>

[szmarczak]

/cc @ronag @mcollina

[mcollina]

This needs a fix in

node/lib/_http_common.js

Lines 225 to 234 in c7a0f1d

	const headerCharRegex = /[^\t\x20-\x7e\x80-\xff]/;
	/**
	* True if val contains an invalid field-vchar
	* field-value = *( field-content / obs-fold )
	* field-content = field-vchar [ 1*( SP / HTAB ) field-vchar ]
	* field-vchar = VCHAR / obs-text
	*/
	function checkInvalidHeaderChar(val) {
	return RegExpPrototypeTest(headerCharRegex, val);
	}

.

Should be a simple fix so I'm tagging it as a good first issue

[mscdex]

We've been down this road before multiple times, the most recent HTTP/1.x RFC specifically calls out that header values should only contain ASCII or characters 0x80-0xFF (latin1).