What is the problem this feature will solve?

HTTP/2 includes restrictions that block any attempt to send multiple values of known single-values headers in requests or responses (here).

This restriction doesn't exist in our HTTP/1 implementation:

const http = require('http');

http.createServer((req, res) => {
    res.writeHead(200, { date: ['a', 'b'] });
    res.end();
}).listen(9000);

This sends two date headers in the response with no problem at all.

Blocking this is a reasonable default imo (normal applications shouldn't send multiple single-value headers) but is problematic as a hard restriction, because there do exist real clients and servers that do all sorts of technically-invalid-but-parseable things like this. Clients & servers in Node.js that need to integrate, proxy or emulate these behaviours run into problems when that's blocked (in my case: httptoolkit/httptoolkit#785).

What is the feature you are proposing to solve the problem?

I'd suggest we add an option to disable this restriction. Technically this appears very easy to do, the question is the API and whether we're happy to do it.

We do currently already have one insecure funky parsing option for HTTP/2 servers and clients: strictFieldWhitespaceValidation.

We could either add a new option like strictSingleValueHeaderValidation defaulting to true, or we could move towards a more general insecureHTTPParser option, just like HTTP/1 (potentially sharing the same --insecure-http-parser CLI option) to allow users to explicitly opt into all of those kinds of insecure settings at once (I think most users who want one kind of insecure validation are likely to want all of them - does that seem plausible?). That would allow users to indicate they want to be able to send & receive content without any validation that's not strictly required for parsing/generating output. In the latter case, I imagine we'd slowly deprecate strictFieldWhitespaceValidation and move towards a world where we maintain a single option.

What alternatives have you considered?

Currently there's no alternatives - it's impossible to send these requests or responses with Node unless you reimplement HTTP/2 from scratch.

Opening this issue to collect opinions on the options and concept generally here, particularly from @jasnell, @apapirovski and @mildsunrise who've touched on this code in the past.