Fails to serve Unity/Brotli

[dakom]

Exporting a WebGL build from unity and then running http-server -o --cors --brotli

I see Serve Brotli Files is true, but I get an error where files like Build/world.framework.js.br are not being served with Content-Encoding: br in the response header.

Ultimately this means Unity WebGL builds are not viewable with http-server

Environment Versions

1. OS Type: OSX
2. Node version: v16.13.1
3. http-server version: v14.1.1

[BaguetteEater]

I'm having the same issue here on windows and trying to serve unity webgl files.

I tried to find a correct mimetype to put in with the option --mimetype but I have been unsuccesful so far.
But I think the way to make it work is this option to force the type on the brotli file.

[github-actions]

This issue has been inactive for 180 days

[cosmoburn]

yup, doesn't work for me either, says the flag is set to true but does not actually serve the files with 'Content-Encoding', 'br'

[github-actions]

This issue has been inactive for 180 days

[KernelDeimos]

The issue here is that the index page links to the actual file Build/world.framework.js.br, even though http-server is capable of responding with the correct Content-Type header when you don't specify the .br extension, like this: Build/world.framework.js. If no world.framework.js exists in that location, but there is a world.framework.js.br, it will send the .br file with the appropriate Content-Type header.

That said, this needs to be fixed. This is partially resolved with #927 (which includes #923) which adds the --force-content-encoding flag. This flag changes the behavior so even if .br is specified the Content-Encoding header is still sent. Changing this behavior without a flag would be a regression.

I'll close this issue when the readdir index page is updated so that both the .br and non-.br paths can be accessed when --force-content-encoding is not specified, --brotli is specified, and a file with the matching uncompressed name does not already exist.