fix(fetch): treat U+0060 (`) as an HTTP token code point

[Khizarc]

This relates to...

No open issue — found by auditing lib/web/fetch/data-url.js against the MIME Sniffing standard.

Rationale

HTTP token code points are defined as:

U+0021 (!), U+0023 (#) to U+0027 ('), U+002A (*), U+002B (+), U+002D (-), U+002E (.), U+005E (^) to U+0060 (`), U+007C (|), U+007E (~), or an ASCII alphanumeric.

HTTP_TOKEN_CODEPOINTS covers ^ and _ but stops one code point short of U+0060:

const HTTP_TOKEN_CODEPOINTS = /^[-!#$%&'*+.^_|~A-Za-z0-9]+$/u

The regex is used in four places, which gives three distinct wrong results:

	current	expected
parseMIMEType('text/pl`ain')	'failure'	a valid MIME type
parseMIMEType('text/plain;a`b=1')	parameter silently dropped	parameter kept
serializeAMimeType with value a`b	x="a`b"	x=a`b

The giveaway is that ^ and _ — the other two code points in that same range — parse fine.

Node's own MIMEType in node:util accepts the backtick in all three positions, so undici is the outlier within the project:

> new (require('node:util').MIMEType)('text/plain;x="a`b"').toString()
'text/plain;x=a`b'

I checked whether #4483 (improve regexes in data-uri.js) introduced this. It did not — that PR moved the - and added the u flag; the backtick was already missing beforehand. This is long-standing, not a regression.

Changes

One code point added to the character class, plus tests covering each of the three affected positions.

Features

N/A

Bug Fixes

• U+0060 (`) is now treated as an HTTP token code point, so it is accepted in a type, a subtype, and a parameter name, and is not quoted when serializing a parameter value.

Breaking Changes and Deprecations

N/A

Status

• I have read and agreed to the Developer's Certificate of Origin
• Tested — 5 new tests, all failing before the change; npm run test:fetch green (481 fetch + 28 webidl + 47 busboy, 0 failures); npm run lint clean
• Benchmarked (optional) — S
• Documented — S, no public API change
• Review ready
• In review
• Merge ready