Null value of Access-Control-Allow-Origin

[ToyB0x]

Describe the bug

It seems that MDN states that null should not be used for the value of Access-Control-Allow-Origin, but looking at the implementation below, it seems that null is returned. (See also 7.4. Avoid returning Access-Control-Allow-Origin: "null")

whatwg-node/packages/server/src/plugins/useCors.ts

Lines 57 to 60 in 1e3b128

	} else {
	// There is no origin found in the headers, so we should return null
	headers['Access-Control-Allow-Origin'] = 'null';
	}

To Reproduce Steps to reproduce the behavior:

Run the existing test below.

whatwg-node/packages/server/test/useCors.spec.ts

Lines 77 to 88 in 1e3b128

	it('should return null if the sent origin does not match', () => {
	const request = new Request('http://localhost:4002/graphql', {
	method: 'POST',
	headers: {
	'Content-Type': 'application/json',
	origin: 'http://localhost:4002',
	},
	});
	const headers = getCORSHeadersByRequestAndOptions(request, corsOptionsWithMultipleOrigins);
	expect(headers?.['Access-Control-Allow-Origin']).toBe('null');
	});
	});

Expected behavior

A server can respond to requests from disallowed origins without including Access-Control-Allow-Origin header.
In this case, the browser blocks the request based on the Same-Origin Policy.

Environment:

• @whatwg-node/server: 0.9.18

[ardatan]

The idea there to let the browser know the server doesn't accept that origin. Let us know if you have better idea for this behavior. And I also see it is not restricted to return null.
We really need e2e browser tests to confirm browser rejects the request if that header is not present.

[ToyB0x]

Looking at the expressjs/cors code, it seems to be testing the absence of a CORS-related header.
Therefore, I don't think it's a bad idea to not return the CORS-related Header itself instead of null.

I agree that it is safer to add browser E2E testing.