Is DNS resolution performed when using request patching?

[vietanhtran16]

Hi,

At the moment, I am doing a request patching using ctx.fetch so that I can use MSW as a proxy to redirect to a local instance of a service that my nodejs application is requesting.

It seems to still performing DNS resolution to the original url instead of just proxying it to the url that I am using ctx.fetch with. Example below. Is this my correct understanding? Thanks

rest.get("https://hello.local", (req, res, ctx) => { // looks like DNS resolution is still being done on `https://hello.local`
  ctx.fetch("http://localhost:3100") // this is where I want to proxy too so thought that it should just call this instead and don't perform DNS resolution for `https://hello.local`
})

[kettanaito]

Hey, @vietanhtran16.

The way request interception works is that whenever a request matching your handler is performed, MSW executes your response resolver, allowing you to decide what to do with that request. Based on this, the GET https://hello.local will be performed first, which implies DNS resolution, then it will be intercepted by the worker (if speaking about browser), and then within the resolver it (worker) will perform a GET http://localhost:3100 request that you can use for response patching.

I believe the behavior is the same if you implement a similar route handler in any server:

app.get('/', (req, res) => {
  const proxyRes = await fetch('http://proxy.example')
})

Both GET / and GET http://proxy.example will be resolved.

Are you experiencing trouble with the DNS resolution for hello.local?

[kettanaito]

No, in Node.js that request would not reach the DNS resolution phase. Node request interception is different.

With the newest versions of MSW, it may perform the lookup but if there's a handler matching this request, any lookup failures will not be actualized so they won't affect/propagate to your code.

[vietanhtran16]

So this is what our handler looks like. We are using 0.44.2 version of msw. When you say it may perform the lookup, would it does it in this case and if it does would any failure affect our code? Since we got rest.all that should match this request, I assume it shouldn't affect our code right?

rest.all(/.*/, async (req, res, ctx) => {
  // load mock config based on req headers
  const mockConfig = loadMockConfig(req) // mock config either specify a redirectTarget or static mock response
  const requestOrigin = req.url.origin
  // if there is a redirectTarget
  if (mockConfig[requestOrigin].redirectTarget) {
    const redirectUrl = new URL(
      req.url.pathname,
      mockConfig[requestOrigin].redirectTarget
    )
    // use ctx.fetch to redirect
    const proxy = await ctx.fetch(redirectUrl.href)
    return res(
      ctx.status(proxy.status),
      ctx.set(headersToObject(proxy.headers)),
      ctx.body(await proxy.text())
    )
  }
  // otherwise check if mockConfig has static mock
  if (mockConfig.data) {
    // use static mock
    return res(
      ctx.status(mockConfig.status ?? 200),
      ctx.json(mockConfig.data)
    )
  }
  // let it passthrough as fallback
  return req.passthrough()
})

[vietanhtran16]

another question, if it does perform DNS resolution and that process takes way too long for .local top level domain, would that affect our code when performing response patching?

I did a test and edited my hostfile with this line, our response patching is working fine. Without that line in hostfile, we just get timeout so that is why I think DNS resolution is being done for hello.local which is timing out and affect our code

127.0.0.1 hello.local

[kettanaito]

DNS lookup in Node shouldn't affect your code if that hostname is mocked. But if I read your use case correctly, ctx.fetch() will hit the actual host, so the lookup is important. If it fails, that actual request will fail. If it takes too long, that actual request may timeout.

It's important to notice that ctx.fetch() just uses node-fetch under the hood.

Make sure your DNS setup is accessible when you're running that test. You can test that in isolation as well:

// iso.js
const fetch = require('node-fetch')

fetch('http://hello.local')

This is the same that ctx.fetch('http://hello.local'). I don't think there's MSW issue around this.

[vietanhtran16]

when our ctx.fetch is called it would call http://localhost:3100 instead since we have updated the base url before performing the redirect

const redirectUrl = new URL(
  req.url.pathname,
  mockConfig[requestOrigin].redirectTarget // redirectTarget's value is http://localhost:3100
)
// use ctx.fetch to redirect
const proxy = await ctx.fetch(redirectUrl.href)