normalizeClientRequestArgs drops request headers when the options object carries URL fields like hash, href, and origin and no method (breaks OTel-instrumented GETs)

[nicki-moody]

Summary

When http.request() / https.request() is called with a single an options object that contains URL fields like hash, href, and origin (as produced by Node's urlToHttpOptions()) and no method, @mswjs/interceptors misclassifies it as a legacy url.parse() URL and rebuilds the request from href alone — silently discarding headers and other request options on passthrough.

This reproduces with MSW alone, but is hit in the wild whenever OpenTelemetry's HTTP instrumentation is also active, because it normaliSes outgoing request(url, options) calls into exactly this shape. It broke the LaunchDarkly Node SDK for us: the SDK's streaming GET reached the server with no Authorisation header → 401. (Its analytics POST was unaffected — it carries a method, so it dodges the heuristic.)

Environment
@mswjs/interceptors: 0.40.0 — also confirmed on 0.41.9 (latest); the relevant code is unchanged.
Node: 24.13
(In production it surfaced via @opentelemetry/instrumentation-http + msw 2.x.)
Reproduction (MSW only — no OTel/SDK needed)

import nodeHttp from "node:http";
import { urlToHttpOptions } from "node:url";
import { http, passthrough } from "msw";
import { setupServer } from "msw/node";

setupServer(http.all("*", () => passthrough())).listen({ onUnhandledRequest: "bypass" });

const echo = nodeHttp.createServer((req, res) => {
  console.log("server received authorization:", req.headers.authorization ?? "(none)");
  res.end("ok");
  process.exit(0);
});

echo.listen(0, "127.0.0.1", () => {
  const { port } = echo.address();
  const url = new URL(`http://127.0.0.1:${port}/x`);

  // The shape OpenTelemetry's instrumentation-http produces for request(url, options):
  // urlToHttpOptions(url) merged with the caller's options, one object, GET (no `method`).
  const options = {
    ...urlToHttpOptions(url),                        // includes hash, href, host, path, ...
    headers: { authorization: "Bearer secret-key" },
  };

  nodeHttp.request(options).end();
});

Actual: server received authorization: (none)
Expected: server received authorization: Bearer secret-key

For comparison, passing the URL as a string — nodeHttp.request(url.href, { headers: {...} }) — preserves the header; it's specifically the single-options-object form with URL fields that fails.

Root cause
In src/interceptors/ClientRequest/utils/normalizeClientRequestArgs.ts

else if ('hash' in args[0] && !('method' in args[0])) {
  // ...treats args[0] as a url.parse() URL...
  const resolvedUrl = new URL(legacyUrl.href)
  return normalizeClientRequestArgs(defaultProtocol, [resolvedUrl, args[1]]) // headers/options dropped
}

The heuristic 'hash' in args[0] && !('method' in args[0]) is meant to detect a legacy url.parse() Url. But an options object built via { ...urlToHttpOptions(url), headers } also has hash (always present, even as "") and, for a GET, no method — so it matches. The branch then re-normalises using only legacyUrl.href, so the caller's headers (and rejectUnauthorized, etc.) never make it to the passthrough request. The object should instead fall through to the else if (isObject(args[0])) branch, which preserves them.

Proposed fix
Exclude objects that carry request options (a real legacy Url never has headers):

- else if ('hash' in args[0] && !('method' in args[0])) {
+ else if ('hash' in args[0] && !('method' in args[0]) && !('headers' in args[0])) {

With this, the options object falls through to the RequestOptions branch and headers are preserved; genuine legacy URLs (no headers) are still handled as before. Verified against the repro above and a real OTel + LaunchDarkly setup.

Repro
Full OpenTelemetry + LaunchDarkly reproduction (with the fix as a patchedDependencies patch you can toggle): https://github.com/nicki-moody/msw-otel-bug-repro — pnpm install && pnpm run repro. Reproduces on msw@2.15.0 / @mswjs/interceptors@0.41.9. The self-contained, no-dependencies snippet in the issue above shows the same header loss without any external services.

Happy to open a PR with the one-line fix if that's useful.

[nicki-moody]

Some additional context that ties this to earlier history and, I think, strengthens the case:

This is the same root cause as #188
#188 reported the identical header-drop in the same normalizeClientRequestArgs legacy-URL branch — there via Node's url.parse() (the eventsource library), here via OpenTelemetry's urlToHttpOptions(). Both produce a single url-shaped options object (hash present, no method, carrying headers) that trips the same heuristic. #188 was closed as needs:discussion with no linked PR, so the underlying bug is still live — confirmed on the latest @mswjs/interceptors@0.41.9.

Why it looked resolved but wasn't
LaunchDarkly worked around #188 on their side: launchdarkly-eventsource passes the URL as a separate string argument — request(urlString, options) instead of a single url.parse() object — so interceptors takes its string branch and keeps the headers. That's a consumer-side workaround, not a fix here, which is why MSW-alone works with LaunchDarkly today.

OpenTelemetry defeats that workaround. @opentelemetry/instrumentation-http intercepts the safe request(urlString, options) call and re-normalizes it (via urlToHttpOptions) back into a single url-shaped options object — re-triggering the latent branch. So this isn't specific to any one library: any layer that normalizes an outgoing request into a url-shaped options object (url.parse, urlToHttpOptions, …) re-exposes it. The && !('headers' in args[0]) guard fixes the root cause so consumers don't each have to work around it.

Full OpenTelemetry + LaunchDarkly reproduction (with the fix as a patchedDependencies patch you can toggle): https://github.com/nicki-moody/msw-otel-bug-repro — pnpm install && pnpm run repro. Reproduces on msw@2.15.0 / @mswjs/interceptors@0.41.9. The self-contained, no-dependencies snippet in the issue above shows the same header loss without any external services.

[nicki-moody]

I have a fix + regression test ready for this, but I can't open a PR — the repo currently limits PR creation to collaborators. The branch is on my fork:

Branch: https://github.com/nicki-moody/interceptors/tree/fix/preserve-headers-on-url-shaped-options
Commit: nicki-moody@8b968db (2 files, +22 / −2)

The change is a one-line guard in normalizeClientRequestArgs — 'hash' in args[0] && !('method' in args[0]) → 'hash' in args[0] && !('method' in args[0]) && !('headers' in args[0]) — plus a test that fails without the change and passes with it (the full normalizeClientRequestArgs suite passes).

Happy to open the PR once the limit lifts, or feel free to cherry-pick the commit.

[kettanaito]

Hi @nicki-moody. Thanks for reporting this. I've just released a complete rewrite of the library in 0.42.0. Could you please update and see if this issue has been fixed?

[kettanaito]

I confirm this bug is no longer reproducible because the entire ClientRequest architecture is gone since #770. normalizeClientRequestArgs isn't a thing anymore, we don't alter or process the ClientRequest args in any way now.

[nicki-moody]

Wonderful, thanks @kettanaito! 🙏

We don't depend on @mswjs/interceptors directly, we pull it in via msw. Forcing interceptors to 0.42.x with a package-manager override installs fine, but then msw throws at runtime:

SyntaxError: The requested module '@mswjs/interceptors' does not
provide an export named 'InterceptorReadyState'

msw/node's setupServer still imports InterceptorReadyState, which was removed in the 0.42 rewrite. And msw@latest (2.15.0) still pins @mswjs/interceptors@^0.41.3, so bumping msw doesn't get us to 0.42 either.

Is there (or is one planned) an msw release that moves to @mswjs/interceptors@^0.42? That's what we'd need to pick up the fix.
Thanks again!

[kettanaito]

mswjs/msw#2692 is already running on the latest interceptors. Please use its preview release from the comments.