Not alter headers for requests

[marcosvega91]

This is a follow up for #678.

When a request is intercepted by MSW a custom header x-msw-request-id is sent through request. This could cause some issues if the request is not handled, for example the server could have some role on access-control-allow-headers that could block the request.

At the same time, we need a way to identify the request. Could be better if we move the identifier into a cookie instead ?

[kettanaito]

Worth mentioning that x-msw-request-id is relevant only when running MSW in Node.js. The purpose of x-msw-request-id is to associate a request with a potential mocked/actual responses through the Life-cycle events.

In the browser, the worker sends all the responses back to the client, with those responses containing a custom appended requestId property in the message (no need to alter request headers):

msw/src/mockServiceWorker.js

Lines 115 to 136 in d101762

	// Send back the response clone for the "response:*" life-cycle events.
	// Ensure MSW is active and ready to handle the message, otherwise
	// this message will pend indefinitely.
	if (client && activeClientIds.has(client.id)) {
	;(async function () {
	const clonedResponse = response.clone()
	sendToClient(client, {
	type: 'RESPONSE',
	payload: {
	requestId,
	type: clonedResponse.type,
	ok: clonedResponse.ok,
	status: clonedResponse.status,
	statusText: clonedResponse.statusText,
	body:
	clonedResponse.body === null ? null : await clonedResponse.text(),
	headers: serializeHeaders(clonedResponse.headers),
	redirected: clonedResponse.redirected,
	},
	})
	})()
	}

If I understand this correctly, the issue has 2 areas to surface:

• When the request is performed as-is by the "interceptors" library. This can happen with both unhandled requests and those requests that have a handler but that handler returns nothing (explicit bypass).
• When calling ctx.fetch(req), since req.headers will contain the x-msw-request-id header attached here:

msw/src/node/createSetupServer.ts

Lines 55 to 57 in d101762

	if (request.headers) {
	request.headers.set('x-msw-request-id', requestId)
	}

The ctx.fetch scenario would also have the x-msw-bypass header appended that's designed to let the worker know which requests to bypass:

msw/src/context/fetch.ts

Line 12 in d101762

headers.set('x-msw-bypass', 'true')

I agree that request headers may not be the best way to store this internal information.

Could be better if we move the identifier into a cookie instead?

That's an interesting idea, but Service Worker cannot access request cookies:

• Why cannot Service Worker access cookies?
• Should a ServiceWorker be able to read HttpOnly cookies? whatwg/cookiestore#37
• Support modifying cookies on an intercepted fetch w3c/ServiceWorker#837

I find the x-* headers being the least invasive option we can take.

[gomorizsolt]

I've just run into this issue as well... the pre-flight request fails due to the x-msw-request-id header is being present in Access-Control-Request-Headers. Any idea on how to get around it without altering the Access-Control-Allow-Headers header?

[kettanaito]

Hey, @gomorizsolt.

Currently, the x-msw-request-id header is always appended to the request headers:

msw/src/utils/request/parseIsomorphicRequest.ts

Line 16 in fe6751f

request.headers.set('x-msw-request-id', requestId)

We don't have an API to opt-out from this behavior, as it would effectively break the functionality of Life-cycle events. We are looking for contributors to help us brainstorm this and, hopefully, migrate from altering request headers for the sake of tracking requests and their responses. If you have any input on this, please don't hesitate to share it in the comments below. Thanks.

[kettanaito]

While the x-msw-reqest-id was relevant only to Node.js interception, the header was set for all environments, as it was set in the parseIsomorphicRequest that's used everywhere. That particular behavior is what caused the CORS issues with the header not being allowed.

Now when the interceptors library generates and sets request.id by itself, we no longer need any additional properties on the request to associate responses with the corresponding requests. I've removed the x-msw-request-id header entirely in #1024.