Headers are not send

[solodeveloping]

Describe the bug

I'm working an a browser extension, I'm using Vue + Vite for the web pages.

I needed to use OPFS, so I had to set Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy.

I added this to the server, and it used to work.

It seems like it's not working anymore, the html file has it but other files don't.

I've checked this, but I'm not using preview #9864

I haven't seen any indication in the doc that the headers should not be always send, the doc is sparse though:

I have this config:

// in the plugins:
    {
      name: 'set-headers',
      configurePreviewServer(server) {
        server.middlewares.use((req, res, next) => {
          res.setHeader("Cross-Origin-Opener-Policy", "same-origin")
          res.setHeader("Cross-Origin-Embedder-Policy", "require-corp")
          next()
        })
      }
    }
  ],
  // WARN : necessary for wasm SQLite
  server: {
    headers: {
      'Cross-Origin-Opener-Policy': 'same-origin',
      'Cross-Origin-Embedder-Policy': 'require-corp',
    },
    watch: {
      ignored: [
        // "./src/options/worker.ts",
        // "./src/options/worker.js"
      ],
    },
  },
  optimizeDeps: {
    include: [
      'vue',
      '@vueuse/core',
      'webextension-polyfill',
    ],
    exclude: [
      'vue-demi',
      '@sqlite.org/sqlite-wasm',
      'quickjs-emscripten'
    ],
  },

Since then, I've updated a few files because I thought the error was from SQLite but it seems it was not.

Reproduction

https://codeberg.org/SoloDeveloping/SemanticNotes

Steps to reproduce

Run pnpm install, pnpm dev, install the extension, open the sidepanel, open the main extension url, and it does not seem to be working anymore.

System Info

System:
    OS: Windows 10 10.0.19045

Browsers:
    Chrome: 147.0.7727.56

Brave 1.89.132 (Build officiel) (64 bits)
Chromium: 147.0.7727.56

Tested on Chrome and Brave.

Used Package Manager

pnpm

Logs

It's present on the html file:

Not present in the main ts file:

Not present in the SQLite file, but requested:

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 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.

[solodeveloping]

Note that the url is in the form http://localhost:3303/@fs/C:/Users/

Not sure it matters since only the html file seem to have it

[solodeveloping]

So, I made some progress.

I've tested a new project (vite create vue + typescript, I installed sqlite WASM)

1. I was using configurePreviewServer instead of configureServer, but since I was using server.headers it should not had mattered
2. server.headers works fine on the new project

So I tried to set the correct configureServer, and the headers are present now:

But if I don't put the configureServer, server.headers does not send them.

Maybe a plugin interfere, I don't know.

The whole thing is true regardless of optimizeDeps (which I thought could be related to it).

If someone encounter something similar: you need to go in the console and disable caching, because headers are cached too.

[vekovius]

What you’re seeing is likely the difference between document responses and module/asset requests, especially in an extension/dev-server setup, not just “Vite randomly stopped sending headers”.

A few things to separate here:

1. COOP/COEP matter primarily on the top-level document

   • Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy are document-level policies
   • the important check is whether the page itself becomes cross-origin isolated
   • seeing them on index.html but not every fetched JS file is not necessarily the real problem by itself

2. server.headers is dev-server response decoration, not a guarantee that every browser-internal or extension-mediated request will look the same

   • especially in browser extension flows, some requests can behave differently from a normal page load
   • if part of the path is being served/resolved through extension machinery, devtools output can be misleading if you expect “all requests must visibly carry the same headers”

3. Your preview middleware is only for preview

   • configurePreviewServer(...) does not affect pnpm dev
   • so for dev, the relevant part is server.headers
   • if you expected the plugin middleware to affect dev too, it won’t

4. For cross-origin isolation, the real thing to verify is self.crossOriginIsolated

   • check it in the page context
   • if it is false, then something in the page/resource graph is breaking isolation
   • common causes are a missing CORP/CORS-compatible subresource, extension constraints, or a worker/wasm path that is not being served the way the browser expects

What I would test next:

• open the affected page and check:
  js
  self.crossOriginIsolated

• if false, inspect:

  • workers
  • wasm/sqlite resource loading path
  • any subresource that needs CORS/CORP compatibility
  • whether the extension environment itself is changing the loading behavior

So I would not assume “Vite should attach these headers to every file request and if not it’s broken”.
I’d verify whether the page is actually becoming cross-origin isolated, because that is the meaningful success condition here.