gmr-prog

Hi, just wondering if there is any update to this. Thanks!

Sent via PM. Thanks!

I have tested this, and yes, it does.

If ESET was re-compressing, I would expect the Content-Encoding: gzip header to remain in the response, but it doesn't. Because it doesn't, if ESET is re-compressing, then the browser would be lost every time, trying to interpret a compressed file as uncompressed. I can't find any reference to "X-Content-Encoding-Over-Network" online other than in conjunction with ESET. I suspect it may be a proprietary header that indicates "this was compressed with GZIP when it reached ESET, but ESET decompressed it and had to remove the Content-Encoding header, so this is the record that that happened".

It is ok if the content is already unpacked by the time it reaches the browser. Our issue is that it appears the content is not always being unpacked correctly, resulting in "ERR_INCOMPLETE_CHUNKED_ENCODING" errors reported by the browser.

I tried that, and with that rule in place, our content does indeed work as expected. While we will still work towards a solution that will resolve the problem completely, this is a useful option to have in case it becomes necessary. Thanks for the information!

PM sent. Thanks!

Yes, we found that Github page and the Stack Overflow page linked in it, among other pages, as part of our research. These pages pointed us in the direction of investigating ESET. Our software is browser-based; it wouldn't be feasible to ask our clients to exclude their web browsers from their security scans.

I generated a log file. Because there is potentially confidential info in there (and this is a public forum), and also because it is over 500 MB, is there an alternate way to submit it directly to you?

We are a vendor of web-based software with multiple clients that use the ESET anti-virus package as a corporate standard. These clients have reported issues viewing our content in Chrome or Edge browsers. Sometimes a page will show up blank, and other times a string of nonsense characters is displayed on the screen. The developer tools revealed the presence of "ERR_INCOMPLETE_CHUNKED_ENCODING" errors when retrieving certain files, intermittently but frequently. We have narrowed down the problem to a conflict between our software and ESET. We do not experience these symptoms when running on machines not equipped with ESET, and we do not experience them when running on a machine with ESET for which specifically the "HTTP(S) traffic scanning" setting has been disabled (just turning off protection doesn't seem to make an impact). What appears to be happening is that we use GZIP compression on files retrieved from our server, and ESET decompresses them to scan them and delivers them to the browser uncompressed with the appropriate headers altered. However, something appears to be going wrong with the decompression, and the results being delivered to the browser are not always correct. In fact, for testing purposes we disabled compression on our server, and the software was delivered correctly with ESET running. Below is a sampling of the response headers that the browser gets when ESET is not running vs. the response headers that the browser gets when ESET is running and the issue occurs. (Monitoring at the server side, the response headers were the same in both cases, other than timestamps.) Is there something we can add to prevent ESET from having these issues? Alternatively, is there a setting that would allow our clients to bypass that scan just for our software? We tried experimenting with the "List of addresses excluded from content scan" setting, but that didn't seem to help. If it matters, our in-house testing has been with ESET Smart Security Premium. Response headers without ESET: Accept-Ranges: bytes Cache-Control: max-age=604800 Connection: keep-alive Content-Encoding: gzip Content-Range: bytes 0-30485/30486 Content-Type: text/html Date: [timestamp] Etag: [text-string] Expires: [timestamp] Last-Modified: [timestamp] Referrer-Policy: strict-origin-when-cross-origin Strict-Transport-Security: max-age=31536000; includeSubDomains Transfer-Encoding: chunked Vary: origin, accept-encoding X-Content-Type-Options: nosniff X-Robots-Tag: noindex, nofollow, nosnippet, noarchive, notranslate, noimageindex, nocache, noodp X-Xss-Protection: 1; mode=block Response headers with ESET: Accept-Ranges: bytes Cache-Control: max-age=604800 Connection: keep-alive Content-Range: bytes 0-30485/30486 Content-Type: text/html Date: [timestamp] Etag: [text-string] Expires: [timestamp] Last-Modified: [timestamp] Referrer-Policy: strict-origin-when-cross-origin Strict-Transport-Security: max-age=31536000; includeSubDomains Transfer-Encoding: chunked Vary: origin, accept-encoding X-Content-Encoding-Over-Network: gzip X-Content-Type-Options: nosniff X-Robots-Tag: noindex, nofollow, nosnippet, noarchive, notranslate, noimageindex, nocache, noodp X-Xss-Protection: 1; mode=block