sveltekit via adapter-node can no longer serve over http2

[Cangit]

Describe the bug

☑️ The following works using

• @sveltejs/kit 1.0.0-next.232
• @sveltejs/adapter-node 1.0.0-next.62

❌ But breaks with the error 400 Bad Request Invalid request body on every route after updating to

• @sveltejs/kit 1.0.0-next.245
• @sveltejs/adapter-node 1.0.0-next.67

import { handler } from './build/handler.js';
import fs from 'fs';
import http2 from 'http2';

const port = 1337;
const server = http2.createSecureServer(
  {
    key: fs.readFileSync('./certs/privkey.pem'),
    cert: fs.readFileSync('./certs/cert.pem'),
    allowHTTP1: false,
  },
  handler
);

server.listen(port, () => {
  console.log('🍱 Server running');
});

Reproduction

Repo with the bug in action can be found here: https://github.com/Cangit/http2bug
(Check the readme)

Logs

No response

System Info

System:
    OS: macOS 12.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
    Memory: 10.60 GB / 32.00 GB
    Shell: 5.8 - /bin/zsh
  Binaries:
    Node: 17.4.0 - /usr/local/bin/node
    Yarn: 1.22.15 - /usr/local/bin/yarn
    npm: 8.3.1 - /usr/local/bin/npm
  Browsers:
    Firefox: 96.0.2
    Safari: 15.2
  npmPackages:
    @sveltejs/adapter-node: 1.0.0-next.67 => 1.0.0-next.67 
    @sveltejs/kit: 1.0.0-next.245 => 1.0.0-next.245 
    svelte: ^3.46.3 => 3.46.3

Severity

blocking an upgrade

Additional Information

No response

[Karlinator]

This sounds like it's similar/related to #3479? That was an issue in the dev server, but it might be the same kind of header parsing issue at play here.

[Conduitry]

It definitely is. One workaround for now would be to strip the HTTP/2 headers from the request before passing it to the SvelteKit middleware. Otherwise we would need to strip them in the adapter or get node-fetch to not choke on these headers or we'd need to fork node-fetch.

[Conduitry]

I suppose alternatively we could just document in the Node adapter readme that the exposed middleware is just intended for HTTP/1 and it's the user's responsibility to adjust the incoming requests if they're HTTP/2.

[Karlinator]

Is there a performance penalty to translating incoming HTTP/2 requests to HTTP/1 in a reverse proxy (beyond just the processing I mean)? I'm not familiar with the details of this, and whether you lose some of the benefits of HTTP/2 when you do that.

As discussed in #2190 (and elsewhere) we do expect users to use a reverse proxy in front of adapter-node in virtually all cases, which can also translate to HTTP/1, though I think we would want something more permanent at some point.