CORS errors and sequence: how to throw a 401 without losing the headers?

[phil-w]

I'm using Sveltekit to build an API which I'll be using from web apps but also mobile aps, so it needs to work cross domain. I realize I could use other frameworks, but I like Sveltekit and I think it ought to be good for this this. My app is static (aside from the api part) and runs on Netlify at the moment.

I'm using a sequence in hooks.server.js which looks like this:

export const handle = sequence(cors, authjs, authorizationHandle)

The cors call adds the headers to allow my client, wherever it is, to access the server API. I'm making a fetch (using Sveltekit fetch or the browser fetch; same result) for a resource I do not have access to but which exists, so I expect a 401 back. I get instead first this, then the 401 I am expecting. I don't know that I don't have access until I try:

Access to fetch at 'https://**.netlify.app/auth/api/user' from origin 'http://localhost:5173' 
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header 
is present on the requested resource. ...

If you look at the sequence:

1. cors adds headers including Access-Control-Allow-Origin. I tested that by forcing a preflight, the headers are working.
2. authjs correctly returns a 401
3. My authorizationHandle logic picks that up and calls error(401). It does not await resolve(event) because it's not authorized

Now I've written this down it seems bleeding obvious that (3) will not "respect" my headers, as it's not "resolving" the event. Instead it's throwing some kind of exception. Is there a way in Sveltekit I can throw a 401 and not have the cors error?

throw error(401) doesn't do that, and neither does error(401), is there a different incantation which will do what I want?

This looks like it may work, but doesn't seem to:

return new Response(null, {
	status: 401,
	headers: {
		'content-type': 'text/javascript',
		'Access-Control-Allow-Methods': 'GET, POST, PUT, DELETE, PATCH, OPTIONS',
		'Access-Control-Allow-Origin': '*',
		'Access-Control-Allow-Headers': '*'
	}
})

All ideas welcome. I could just ignore the error but that seems unwise.