mmstick, what part of "I have actually tested this" do you not understand? I am not assuming anything. Please stop skimming my comments looking for things you c

mmstick, what part of "I have actually tested this" do you not understand? I am not assuming anything. Please stop skimming my comments looking for things you can try to argue against and actually read the damn things. > It states right there on both of the pages from Google that I linked to you. Brotli will not work without HTTPS. Again, you don't understand what you're actually reading. There are two parts to Brotli support. The first is whether the browser will declare that it supports Brotli. This is the Accept-Encoding header. The second is whether the browser will actually correctly interpret a response encoded as Brotli. HTTPS only affects the first part. Chrome only declares to the server that it can accept Brotli when sending an HTTPS request and not when sending an HTTP request. But if the server ignores the Accept-Encoding header and hands back a Brotli response anyway (like your server is doing), Chrome will handle that exactly the same way over HTTP as it does over HTTPS. Because it's just a content encoding, and there is literally no reason to make the code that handles content encodings care about HTTP vs HTTPS. > Enable HTTPS and pages decode. Switch to HTTP and they do not decode. End of story. Please try testing this, because I promise you this is wrong. Switch to HTTP and if the server returns a Brotli-encoded response (with the Content-Encoding header set correctly) Chrome will still decode it. The only thing HTTPS controls is the contents of the Accept-Encoding header and not the actual behavior of the response decoder. I have tested this multiple times against Chrome 58.0.3029.110, using both localhost and a remote server. You clearly have not, and in light of this your final sentence is particularly ironic.