Allow setting HTTP response headers for browser tests

[DallasHoff]

Clear and concise description of the problem

Certain browser APIs like SharedArrayBuffer require cross-origin isolation. To enable this, the web page must be served with the below HTTP headers.

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Vitest does not currently allow browser tests to set HTTP headers, so testing features that require cross-origin isolation is currently not possible.

Suggested solution

To enable this in the Vite development server, I use the following in the Vite config. Perhaps Vitest should read this same configuration to allow developers to modify the browser test's response headers.

plugins: [
  {
    name: 'configure-response-headers',
    configureServer: (server) => {
      server.middlewares.use((_req, res, next) => {
        res.setHeader('Cross-Origin-Embedder-Policy', 'require-corp');
        res.setHeader('Cross-Origin-Opener-Policy', 'same-origin');
        next();
      });
    },
  },
],

Alternative

No response

Additional context

No response

Validations

• Follow our Code of Conduct
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.

[sheremet-va]

Can't you do the same for browser tests? It uses the same config file.

[DallasHoff]

Can't you do the same for browser tests? It uses the same config file.

As I said, that is the config that I am using, but the headers for browser tests are not affected.

[hi-ogawa]

I think the issue might be due to vitest:browser plugin having enforce:pre, which steals html requests before your middleware:

vitest/packages/browser/src/node/index.ts

Lines 15 to 34 in 7006bb3

	{
	enforce: 'pre',
	name: 'vitest:browser',
	async config(viteConfig) {
	// Enables using ignore hint for coverage providers with @preserve keyword
	if (viteConfig.esbuild !== false) {
	viteConfig.esbuild ||= {}
	viteConfig.esbuild.legalComments = 'inline'
	}
	},
	async configureServer(server) {
	server.middlewares.use(
	base,
	sirv(resolve(distRoot, 'client'), {
	single: false,
	dev: true,
	}),
	)
	},
	},

I think your can counter against this by setting enforce: "pre" on your plugin as well.
I tested locally and it seems to work:

it("repro", () => {
  expect(crossOriginIsolated).toBe(true);
  expect(SharedArrayBuffer).toBeDefined();
})

---

Side note: There seems to be a plan to run each test file in a separate iframe #3584, so if this landed, crossOriginIsolated related quirks might become more complicated?

[sheremet-va]

I think the issue might be due to vitest:browser plugin having enforce:pre, which steals html requests before your middleware:

Maybe we can also add our middleware in the "after" hook like this? Will this fix the issue?

configureServer(server) {
  return () => {
    server.middlewares.use(...)
  }
}

[hi-ogawa]

Maybe we can also add our middleware in the "after" hook like this? Will this fix the issue?

It seems "after" hook middleware doesn't work when vite config has appType: "spa" (which is the case by default).
The reason is that, unless appType: "custom", Vite server sets up htmlFallbackMiddleware to rewrite all unknown requests into req.url = "/index.html", so this will break vitest:browser plugin's sirv middleware, which is meant to serve its own assets (e.g. dist/client/index.html, __vitest__browser__/index....js, etc...).

I don't know about the consequence of forcing appType: "custom", so as an alternative, it might make more sense to remove enforce from vitest:browser plugin instead.

[userquin]

can you try using viteServer.middlewares.stack.push in your plugin?

[DallasHoff]

I think your can counter against this by setting enforce: "pre" on your plugin as well.

Side note: There seems to be a plan to run each test file in a separate iframe #3584, so if this landed, crossOriginIsolated related quirks might become more complicated?

Adding enforce: "pre" does fix the issue for me for now.

If the tests are changed to run in separate iframes, there will need to be a way to directly customize the response headers of the frames. Hopefully that is accounted for.

[hi-ogawa]

As explained in the other issue #4888, Vitest browser mode now respects Vite's server.headers config, so the same thing can be achieved without custom plugin:

import { defineConfig } from 'vite';

export default defineConfig({
  server: {
    headers: {
      "Cross-Origin-Embedder-Policy": "require-corp",
      "Cross-Origin-Opener-Policy": "same-origin"
    },
  },
});

[DallasHoff]

As explained in the other issue #4888, Vitest browser mode now respects Vite's server.headers config, so the same thing can be achieved without custom plugin

I just tried this out with the latest versions of Vite and Vitest. It works when running the tests, but when running the app in the Vite dev server, the headers are not applied.

[hi-ogawa]

when running the app in the Vite dev server, the headers are not applied.

Thanks for testing. Hmm... that could be a Vite side bug since server.headers are intended to work especially for setting coop/coep headers at least vitejs/vite#8481 (comment)

This issue vitejs/vite#15641 is reported recently on Vite and it might be possible that you're seeing "304 Not modified" in devtools, but a browser should be aware of last response's header with coop/coep, so I didn't see any issue with 304 response (you may also try "disable cache" on devtools to see if it makes difference). If this also not the case, then it would be great if you can provide a reproduction and submit it as Vite issue.

(Actually Vite's 304 response might be quite annoying since this probably happens also when users are tweaking server.headers but it won't be reflected immediately until you disable cache. I'll dig into this later.)