HMR does not work with proper SSL certificates

Describe the bug

I created a ZeroSSL certificate for the development environment because most browsers disabled http access to any domain other than localhost.

vite.config.ts

import { svelte } from '@sveltejs/vite-plugin-svelte'
import fs from 'fs'
import { defineConfig } from 'vite'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [svelte()],

  server: {
    https: {
      key: fs.readFileSync('./cert/app.loc.depoxy.dev.key.pem'),
      cert: fs.readFileSync('./cert/app.loc.depoxy.dev.crt.pem'),
    },
    hmr:{

    }
  },
  optimizeDeps: {
    exclude: ['@sveltestack/svelte-query'],
  },
})

Reproduction

This is reproducible

System Info

> npx envinfo --system --npmPackages '{vite,@vitejs/*}' --binaries --browsers

  System:
    OS: macOS 11.6.2
    CPU: (8) arm64 Apple M1
    Memory: 554.27 MB / 16.00 GB
    Shell: 3.3.1 - /opt/homebrew/bin/fish
  Binaries:
    Node: 14.18.1 - /opt/homebrew/opt/node@14/bin/node
    Yarn: 1.22.17 - /usr/local/bin/yarn
    npm: 8.1.0 - /opt/homebrew/bin/npm
  Browsers:
    Brave Browser: 98.1.35.101
    Safari: 15.0
  npmPackages:
    vite: ^2.6.4 => 2.8.3

Used Package Manager

yarn

Logs

Failed to load resource: net::ERR_HTTP2_PROTOCOL_ERROR

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn’t already an issue that reports the same bug to avoid creating a duplicate.
• Make sure this is a Vite issue and not a framework-specific issue. For example, if it’s a Vue SFC related bug, it should likely be reported to https://github.com/vuejs/core instead.
• Check that this is a concrete bug. For Q&A open a GitHub Discussion or join our Discord Chat Server.
• The provided reproduction is a minimal reproducible example of the bug.

[CristianHG2]

FYI: This might be a duplicate of https://github.com/vitejs/vite/issues/1653

---

Experiencing the same issue here. Seems to come and go between reloads in my case, these are some of the patterns I’ve noticed if it helps anyone:

• Issue seems most prominent during the initial bootup of the dev server
• I’m guessing it’s not framework/library-specific, we use React and experience the same errors
• Modules seem to be cached and are not re-built until a change happens
• A bulk of the errors we’ve seen happens during initial builds and re-builds of largely interconnected components

All in all, I’m thinking it could be some sort of timing mismatch between Vite’s response/dispatch and ESBuild finishing. It also flares up when we have errors or under-performance from our linting plugins (TSLint/ESLint), which again affects timing which might play a role here.

I am going to spend some time looking at the net internals to see if I can find anything else of interest, but I’m not a network engineer so can’t promise much lol.

Some potential workarounds/solutions:

• Best approach will probably be using a reverse proxy like Nginx and then using proxy_pass. This way you can receive TLS requests on your Nginx virtual site and you can then have Vite serve the response through Nginx, which should show at least an improvement given Vite seems to work perfectly without SSL/HTTP2 settings.

• I’ve also been able to mitigate the error significantly by implementing this server setting on my Vite config:

const viteBaseUri = 'https://baseuri.test/';

// I got this solution from another issue, unfortunately, I was unable to find the original issue I found it in. But unless I'm completely misunderstanding I believe this essentially forces Node's HTTP server to downgrade to HTTP 1.1

// There's also some additional solutions I haven't tried that are more oriented specifically towards HMR config here:  https://github.com/vitejs/vite/issues/1653

export default defineConfig({
  server: {
    proxy: {
      [viteBaseUri]: viteBaseUri
    }
});

[sapphi-red]

Closing as this wasn’t able to reproduce and there isn’t enough information. If you still have not made it work, please create a new discussion or issue.

FYI Container related comments are not related to this issue.