fix: defaultCompressibleTypes regex issue

[rumoursbehindme]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the bug has not already been reported

Fastify version

4.28.0

Plugin version

No response

Node.js version

20.16.0

Operating system

Windows

Operating system version (i.e. 20.04, 11.3, 10)

10

Description

If content-type is "[application/force-download]" defaultCompressibleTypes won't allow it.
Then it will goto

const data = mimedb[type.split(';', 1)[0].trim().toLowerCase()]
  if (data === undefined) return false
  return data.compressible === true
}

In this [].split() will throw error.

Link to code that reproduces the bug

No response

Expected Behavior

No response

[rumoursbehindme]

Sorry My fastify version is : '4.28.0'
And fastify-compress version: '7.0.3'

[mcollina]

Thanks for reporting! Would you like to send a Pull Request to address this issue? Remember to add unit tests.

[FayeqAqib]

Can you assign this to me?

[gnotos]

@FayeqAqib are you still working on this? If not I'd like to pick it up.

I looked into this on the current main (v9.2.0). The root cause isn't the regex — it's that shouldCompress assumes type is always a string:

const data = mimedb[type.split(';', 1)[0].trim().toLowerCase()]

Fastify allows header values to be arrays, and then .split doesn't exist. Small repro against the current code:

"application/force-download"   -> false
["application/force-download"] -> TypeError: type.split is not a function
["text/html"]                  -> true
123                            -> TypeError: type.split is not a function
undefined                      -> TypeError: Cannot read properties of undefined (reading 'split')

Note the inconsistency: ["text/html"] returns true because RegExp.test coerces the array to a string and returns early, so it never reaches the failing line. Whether an array content-type works or throws depends on whether it happens to match the regex — which is probably why this looked random to the reporter.

Happy to send a PR that normalises type before the lookup, with unit tests for the array / non-string cases, as @mcollina suggested.