Why is .js.gz file not being served?

I gzipped my app.js to app.js.gz and then ran http-server -g, as specified in the readme of this website.

But my browser still receives the .js file, not the .js.gz file, as you can see in the screenshot. Is this is a bug?

[the0neWhoKnocks]

@thescientist13 as I stated above, it worked if you generated your own gz files. The issue I was having was that if I enabled/passed a flag saying “turn gzip on”, I was expecting the server to do the gzip’ing on the fly. I’m fine with generating the files manually (now that I know that’s what I was supposed to do). It was just frustrating at the time since I wasted time thinking it was user error. Really what the --gzip flag does, is say “if a gz version of a file exists, I’ll use that instead” - not “I’ll now gzip and serve specified file types”.

[the0neWhoKnocks]

I’m running 0.10.0, looks like the gzip PR’s in there, but I’m still not seeing gzipped content come through. I’m running http-server ./build --gzip -o -p 8080.

After reading through ecstatic’s docs, https://www.npmjs.com/package/ecstatic#optsgzip led me to what @RichardJECooke tried (to manually create a .gz file). After doing so, I’m seeing that file served.

The confusion seems to come from the fact that most servers that have a “simple setup” (and gzip is one of the available options), the server will do the work of gzipping for you (which is what I expected). This should really be called out in the docs to lessen confusion.

Possible solutions to anyone that come across this issue:

• Ask the ecstatic folks to update the middleware function to utilize the built in zlib module so files get automagically served up gzipped.
• If you’re utilizing WebPack to build out assets, you can use the CompressionPlugin to generate the .gz files at build time with a configuration like this

new CompressionPlugin({
  asset: '[path].gz[query]',
  algorithm: 'gzip',
  test: /\.js$|\.css$|\.html$/
})