Why is .js.gz file not being served?

[RichardJECooke]

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?

[RichardJECooke]

Update: If I change my index.html to request app.js.gz directly it all works. But I thought the whole point of gzipping is that it's done invisibly - your browser can request a normal .js file and secretly receive the .gz one

[derhuerst]

In chrome dev tools, check the "Transferred" column or the Content-Encoding for a single request.

Only because you see app.js, that doesn't mean it has been transferred uncompressed.

[RichardJECooke]

If I delete the .js file, so http-server is forced to server the .js.gz file, I get a browser error. So it's definitely not working.

[derhuerst]

That's also not how transparent gzipping works. Usually, the server gzips on-the-fly, so the url points to the ungzipped file.

I will have a look in a minute.

[derhuerst]

lib/http-server.js looks like you have to pass gzip: true. Have you done that?

To test it, put an ungzipped file in the directory and check the Content-Encoding header in Chrome or curl -v.

[RichardJECooke]

Yeah, my understanding is that it should gzip on the fly too - I'm used to how IIS works. But the documentation on this site says using -g will serve a .js.gz file if it exists, implying you have to create it yourself.

So now I tried deleting my manually created .gz file to see if maybe http-server zips it automatically. But it doesn't:

[RichardJECooke]

I don't know what you mean by pass gzip: true. I'm running http-server -g

[derhuerst]

I agree that it should gzip on http-server --gzip. I was referring to the usage from Node.js, this is the command line equivalent.

Regarding your screenshot: It's not about Content-Type, it's about Content-Encoding. But that is missing as well.

I will check on my computer in a few minutes.

[derhuerst]

The gzip option has been introduced in b456b77, which has not been published to npm yet. You can check by running npm info http-server@latest gitHead.

You will have to wait until this is published or use http-server@indexzero/http-server (Git dependency).

[intellix]

damnit, was also wondering why my gzip wasn't working after looking at the code :(

[cgatian]

Sadly, this is not in the 0.9.0 release.

[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$/
})

[BigBlueHat]

@the0neWhoKnocks I definitely agree we need to make this clearer in the docs. I'm not sure, though, that we should add any compression magic to the code--as it goes a bit against the whole static server thing. It would be good to have more docs and tests around this bit, so it's more obvious how it works and what steps one needs to take to use it.

[the0neWhoKnocks]

@BigBlueHat Agreed. Calling out that this module is a static server would be good to add to the README as well. There's not one mention of that there.

[thescientist13]

Running 0.11.0 and can confirm gzip now works as expected (I'm generating my own *.gz files with webpack)

Thanks for all the good work! ✌️

[BigBlueHat]

Great to hear @thescientist13!

I'd love some tests for this added, so we can be sure to avoid regressions. I'll leave this open for anyone interested in sending a PR to improve the tests and/or README.

[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".

[thornjad]

The gzip option in the README now specifies that it looks for an existing file. Since there are plenty of tests in ecstatic around gzip (and brotli), I'm going to consider this done.

[Nashorn]

This does not work at all. .gz file created, -g and --gizp flag usdD. Only the .js loads.
Altering <script> tag ref to .gz file, loads but won't decompress.

This thread needs reopening

[thornjad]

@Nashorn What is the content-encoding response header for that file?

[musema]

This does not work at all. .gz file created, -g and --gizp flag usdD. Only the .js loads.
Altering <script> tag ref to .gz file, loads but won't decompress.

This thread needs reopening

were you able to fix providing gzip content to <script> tag?