undici's new Request is incompatible with HTTP/2 requests
#11365
Comments
|
It looks like @Conduitry removed the previous workaround in #7142 (which had been added in #3572). I'm not sure what's different about Vite 5 that's triggering this issue now |
|
I generated my certs with import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';
import { readFileSync } from 'node:fs';
import { resolve } from 'node:path';
import type { ServerOptions } from 'vite';
export default defineConfig(({command}) => {
switch (command) {
case 'serve':
const { key, cert } = JSON.parse(
readFileSync(resolve(__dirname, 'path/to', '__certs', 'www.json'), 'utf-8'));
const server: ServerOptions = {
host: 'www.acme.test',
port: 3002,
strictPort: true,
https: { key, cert },
// without the proxy does NOT work.
proxy: {}
};
return {
server,
plugins: [sveltekit()]
}
default: return { plugins: [sveltekit()] }
}
});the helper function i came up. const { createCA, createCert } = require('mkcert');
const { writeFileSync, readFile } = require('node:fs');
const { resolve } = require('node:path');
(async () => {
const { key: caKey, cert: caCert } = await createCA({
organization: 'ACME CA',
countryCode: 'GR',
state: 'Attica',
locality: 'Athens',
validity: 365
});
try {
await readFile (
resolve(__dirname, 'path/to', '__certs', 'www.json'),
'utf-8'
) // DO NOTHING
} catch (error) {
// ELSE CREATE A NEW CERT
const wwwCert = await createCert({
ca: { key: caKey, cert: caCert },
domains: ['127.0.0.1', 'localhost', 'www.acme.test'],
validity: 365
});
writeFileSync(
resolve(__dirname, ''path/to', '__certs', 'www.json'),
JSON.stringify({ key: wwwCert.key, cert: wwwCert.cert }, null, 2)
);
}
})()for a work round.. |
|
May related to #11213 For workarounds, you can try downgrade Node.js to v20 or try disable HTTP/2 in your browser. |
|
I have the same issue while upgrading to vite 5 and using node 21. |
|
I'm using the solution @Elsoberanold provides in the last paragraph (Additional Information) with a tiny change, import basicSsl from '@vitejs/plugin-basic-ssl'
import { defineConfig } from 'vite';
export default defineConfig({
server: {
https: {}
},
plugins: [basicSsl(), sveltekit()]
});```This way you force HTTPS but it also let you run with Update:After few days (and few minor version updates in Node 21) I had exact same error @Elsoberanold shares above with this plugin config. |
|
Downgrading to node 20 worked initially, but then it would crash with a "Transfer-Encoding" header being present. Adding export default defineConfig({
server: {
https: {
...
},
proxy: {},
},
...
}) |
|
I've just run into this after updating to 20.12.1 Log |
|
@mattpilott I also did get that error again (I guess it was last week or early this week) and then updated my packages, clean install and run it in Node 21 latest this time. Added |
|
@bogacg yes proxy worked for me too! |
|
I tested different recent node versions to see where it broke and it seems v20.12.1 is where this error occurs for me. |
|
A simple downgrade from v20.12.1 back to v20.11.0, without any other config file change, worked here. |
|
@kamerat I see the same. The error occurs when upgrading from Node v20.12.0 to v20.12.1. The Here's the changelog. Based on the stracktrace above, the error is being thrown in the undici library, which seems to have been updated from v5.28.3 to v5.28.4 in Node v20.12.1, but I'm having trouble seeing what specifically should have changed between these versions to cause this error. Interestingly, it seems that there was an attempt at fixing this a long time ago in Sveltekit which was then reverted back again: #7142 Update 2024-05-02 This is also an issue on Node 22.1.0 |
|
I just upgraded a project to SvelteKit 2 (2.7.1), and I believe I'm experiencing a similar issue with a different error log. I'm using vite-plugin-mkcert@1.17.6 to enable the https server. I was using node v20.18.0. Downgrading to v20.11.0 as suggested above was also a functional workaround for me. |
- refactor: share code to detect relative URLs and apply it in other places with potential absolute URLs, as only relative URLs should be handled by SK's goto()
- refactor: replace our own implementation of PaymentElement, which was added to support passing options to it, with the updated upstream svelte-stripe component that also supports it
- build(deps): update packages that needed to be updated for SvelteKit v2 support
- remove now-irrelevant { server.https } option from the vite config (vite v5)
- locks node to v20.11.0 in the root to enable https in the dev server, see sveltejs/kit#11365 (comment)
- some docs fixes
|
@benmccann Even though this issue was initially about https, it might still have (re-)surfaced a potential issue with the The Funny enough, the specific error message changes a bit over time:
I have added a minimal reproduction here: https://github.com/dlebech/sveltekit-11365 Perhaps the discussion is more relevant to continue in #1451 though? |
|
that reads a lot like the undici version used in node was being updated and contains changes that are incompatible to what sveltekit has been doing. We had a lot of issues early on with undici not behaving to spec or doing breaking changes in minors. Are you sure the calls sveltekit is doing are outside of what should be possible with the fetch api and headers? I'd look into the error thrown, the call made to fetch api and report it to undici |
|
@dominikg Yes, I believe the error is thrown by undici, because it rejects any header name that contains a colon
Whether or not this rejection is according to spec is a question that I can't find a definitive answer to, but it kind of makes sense it would reject a http/2 specific header, when undici brands itself explicitly as a http/1.1 client. Either way, Sveltekit's usage of In other words: I am suggesting that Sveltekit probably shouldn't wrap/recreate the incoming request as a (technically) fetch request at all, or at least if it does, then ensure that it can in fact be converted correctly for both http/1.1 and http/2. But then it's probably more appropriate for discussion in the open thread here: #1451 (In my specific case, the incoming |
|
undici supports http/2 behind a flag and they mentioned wanting to support h2c too, maybe file a request with them to get the ball rolling? I believe their end would be the most beneficial to solve this for the wider community, if we worked around it here, other implementations would also have to work around it. Either way if they confirm that they do not want Request to be able to be used this way, we have confirmation that work is needed on our end. |
benmccann
changed the title
new Request is incompatible with HTTP/2 requests
|
Yeah, I think I'm coming to the same conclusion that undici's So I think we have two options here:
Option 2 sounds far harder to implement, so I would lean towards option 1 |
Describe the bug
After migration to SvelteKit 2 serving throw https just stopped working. It does not crash on execution but at the moment we reach exposed endpoint it returns the following error:
Reproduction
This error can be reproduced by starting a new SvelteKit 2 project and changing vite.config.ts accordingly with documentation provided here: https://vitejs.dev/guide/migration#remove-https-flag-and-https-true . I have tried to use https://github.com/vitejs/vite-plugin-basic-ssl and https://github.com/liuweiGL/vite-plugin-mkcert both with same result.
vite.config.ts file:
Severity
serious, but I can work around it
Additional Information
I think that should be a resurgence of this issue: #3479
I have tryed this work around and it works:
vite.config.ts:
The text was updated successfully, but these errors were encountered: