Doesn't seem to perform compression when running on Windows.

[chriseaton]

We have a really odd issue. We're using the standard configuration, and making requests to the server, everything looks correct even up to the point we flush the request, but for some reason, the output is not compressed and the headers are missing on Windows.

Oddly, if we run the exact same code on Linux, the output is compressed.

We're not using a proxy or anything.

Here's our output of getHeaders at the end of our response:

content-encoding:"gzip"
content-type:"application/json; charset=utf-8"
etag:"W/"1e928-ejrkE6/bCZuNbsnF8HFNVEAq/EU""
vary:"Accept-Encoding"

Here's what the browser is showing (and no, the size is not showing the compressed size):

You can see the eTag is the same.
No idea what's going on here - any help would be appreciated.

[dougwilson]

Very strange indeed, @chriseaton ! I only have Windows to develop on, and that is the platform I develop this module on normally, so it is very strange that it is not working on that platform. I just ran the test suite on Windows (64 bit, Windows 10 1803) and everything passed (it sets up a full server and makes requests internally).

A simple Node.js app also seems to work for me using Chrome 70.0.3538.67 . Here is the app I created just now:

const express = require('express')
const compression = require('compression')

const app = express()

app.use(compression())

app.get('/', (req, res) => {
  const obj = {}
  for (let i = 0; i < 100; i++) { obj[i] = 'foobar' }
  res.json(obj)
})

app.listen(3000)

And here is a screenshot of loading the / page:

Any instructions you can provide to help me reproduce the issue would be awesome!

[chriseaton]

Hmm... so what's strange is I just ran your demo app - and it didn't compress for me:
I'm on Windows 10 Pro.
Trying on Chrome and Edge, both produce non-compressed responses... very wacky:

Chrome

Edge

This is the weirdest thing I've seen - because it even seems to leave the app with all the proper headers. What's odd is I also deployed this to a Windows 2012 R2 Server and had the same responses.

[dougwilson]

Are you sure you don't have some sort of WAF installed on the machine that is silently uncompressing responses? Perhaps, does this happen for requests over HTTPS vs over HTTP? If it only happens on HTTP, it would seem to point to somethig on your machine is hijacking your traffic at some point, since a HTTPS request is encrypted to the web browser.

I've seen a few people report no compressing here and it turned out to be an anti virus or other scanning software that embeds into your network stack.

[chriseaton]

That's an interesting thought - I just tried FF on Windows Server 2012 R2, and no dice either:

Both systems do have AV - the above is a pretty barebones server, so I'll temporarily remove the AV on mine and re-run... I don't have any proxies installed or anything that I can think of that would interfere with http requests.

[dougwilson]

Well, I would suggest the next step is to install Wireshark and get a packet capture of the packets coming from the Node.js server to verify if that is compressed or not. If it is, you have something tampering with your traffic somewhere.

[dougwilson]

As for your Edge and Firefox screenshots, it's hard to say, as this module does not compress 304 responses, because a 304 response has no body over the wire to compress.

[chriseaton]

You were right - after removing the AV and rebooting, it now shows compressed.

Interesting side note: both Windows systems had different antivirus's running and both transparently decompressed the http stream. Guess it must be common in the industry. Good to know!

Thanks for your help!

[dougwilson]

Ah, glad you found it! I was just about to check out Firefox / Edge on my side to check what they were doing for me. Yea, it's usually when they have a web anti virtual function that they do this -- they don't use a proxy (so you don't see a proxy anywhere): they typically hook directly into the Windows networking stack and so are completely transparent to any tool you'll use (but they cannot scan HTTPS traffic since at that level it's just ciphertext so you won't see the compression lost on HTTPS traffic only HTTP) or they use DLL injection directly into your web browser processes (they can scan HTTPS this way, but it can cause web browser instability -- a process explorer tool showing loaded DLLs in a given process would reveal this).