Can MSW mock Brotli-compressed responses?

[franky47]

Context: I'm testing an internal API to measure the user-facing benefits of compressing its responses (XML files, which compress nicely with Brotli).

However I'm having a hard time mocking this in MSW. I have a base64-encoded string of a Brotli-compressed XML in my handler, which I decode to a byte array, and have tried the following to send it as a response:

import { b64 } from '@47ng/codec'

const base64String = "..." // XML encoded with Brotli, then base64 encoded

http.get('/path', async () => {
  const compressedPayload = b64.decode(base64String).buffer // ArrayBuffer
  return HttpResponse.arrayBuffer(compressedPayload, {
    headers: {
      'content-type': 'application/xml',
      'content-encoding': 'br'
    }
  })
})

Now when I fetch this, the resulting text payload is not the decompressed XML, but the binary compressed payload, as if fetch failed to decompress. Response headers are correctly set.

Is this a limitation of where ServiceWorkers intercepts are placed in the HTTP stack?

Edit: adding a reproduction repository (as getting MSW to work in online sandboxes is tricky):
https://github.com/franky47/msw-brotli-test

[kettanaito]

Hi, @franky47.

MSW itself isn't responsible for compressing/decompressing the response. If you return a mocked compressed response, I expect you to decompress it at some point. Whatever you return from the handler is what your fetch() receives.

I haven't played enough with compression to provide more details. I'm not sure which layer does the actual decompression when you fetch resources in the browser. I'd expect that to be the browser.

I recommend reproducing a working scenario, then carefully comparing it with your mock. Chances are, there are subtle differences in the response that result in the compression not working as you expect.

[kettanaito]

Update

mswjs/interceptors#604 will handle Brotli (and other) decompression for fetch in Node.js.

As for the browser, I expect the native fetch API to do the decompression for you once the worker sends it the compressed response instance. If it doesn't, I don't support we should be decompressing it either since that's how fetch behaves by default.