3 ms·

> This is completely incorrect. Not only does Brotli have literally nothing to do with the transmission medium and whether it's encrypted, but just to be sure I

> This is completely incorrect. Not only does Brotli have literally nothing to do with the transmission medium and whether it's encrypted, but just to be sure I just tested it and Chrome was perfectly happy to render a Brotli-encoded response over unsecured HTTP. I highly doubt that you actually tried this in practice. You are merely assuming that it works. For Google to overturn their decision would fly against all reasoning for the decision in the first place. > My best guess here is you've confused HTTP/2 (which requires SSL) with Brotli encoding. You seem to not have any experience with Brotli support and why the decision was made to only support it over HTTPS. One such comment that outlies the reasoning is from a Google employee themselves ( https://bugs.chromium.org/p/chromium/issues/detail?id=452335#c87 https://bugs.chromium.org/p/chromium/issues/detail?id=452335... ). Hence, all vendors have followed suit and are not implementing brotli for HTTP. SSL prevents all the middle man infrastructure in place from employing such tactics that would break websites serving content with the br content encoding. There still exists much infrastructure in place that snoops HTTP traffic and, when it is detected that the content encoding is an unknown format (brotli), it will compress the stream with gzip and change the content encoding to gzip, thus breaking the website. In addition, yet again, Google engineers clearly state that Brotli support is only available over HTTPS connections! https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/JufzX024oy0/WEOGbN43AwAJ https://groups.google.com/a/chromium.org/forum/#!msg/blink-d... One of the big reasons for my decision in pursuing HTTPS support on my personal blog was so that I could, in fact, use Brotli. I already had the code in place, but enabling Brotli on my web server would merely give errors about the content encoding being unknown, and as you will notice, br is missing from the list of available accepted encodings by the browser! Yet it is there when connecting via HTTPS! That's because Brotli is completely and utterly disallowed over HTTP! Google engineers stated it themselves. You can't have it both ways.

eridius 9y ago
> I highly doubt that you actually tried this in practice. I told you explicitly that I tested it. Now you're calling me a liar. I am not "merely assuming that it works", I actually tested it to the point of controlling the exact bytes that the server sent to the client using a hand-constructed HTTP response and then pointing Chrome at that server. > For Google to overturn their decision … I just looked into the specific behavior here. Here's what I found: * If you point Chrome at localhost, it includes "br" in the Accept-Encoding header. * If you point Chrome at some other domain using HTTP, it does not include "br" in the Accept-Encoding header. * Either way, if the server actually returns a Content-Encoding of "br", Chrome will respect it. So basically, Chrome always supports Brotli-encoded responses. However, it only requests Brotli over HTTPS and doesn't request it over HTTP, and the only reason for this distinction is to avoid middleware servers from mucking with Brotli-encoded pages that they don't understand.
- mmstick 9y ago
  No, No, and No. Google engineers have repeatedly declared that Brotli requires HTTPS, because they do not allow it's use of HTTP. You cannot use Brotli over HTTP. You are merely assuming that you can. I am stating that you are lying because you can't have it both ways -- either Google engineers are lying about what their software does, or you are lying about what their software does. It states right there on both of the pages from Google that I linked to you. Brotli will not work without HTTPS. I should know as that's one of the main reasons why I moved to implement HTTPS. It's right there in my latest article on my website before I posted it here. Brotli does not work without HTTPS. Enable HTTPS and pages decode. Switch to HTTP and they do not decode. End of story. You're not very bright to continue arguing against this.
  - eridius 9y ago
    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.
rhblake 9y ago
So lemme try to clear this up. You are right in that brotli decoding is only supposed to work in secure contexts (so technically not just HTTPS, btw -- localhost is also considered a secure context, see https://bugs.chromium.org/p/chromium/issues/detail?id=624426 https://bugs.chromium.org/p/chromium/issues/detail?id=624426). Eridius is right in that it currently does work over insecure HTTP in Chrome, as confirmed in this open bug: https://bugs.chromium.org/p/chromium/issues/detail?id=579606 https://bugs.chromium.org/p/chromium/issues/detail?id=579606 -- in which one Chromium dev comments "Decoding brotli even if it isn't requested is both bug and feature. It allows developers to test brotli without setting up https serving." Seems like they concluded that it is indeed a bug, however. Reality and specifications often diverge... (I do think not supporting gzip is absolutely bizarre, but that's another issue.)

eridius 9y ago

> I highly doubt that you actually tried this in practice. I told you explicitly that I tested it. Now you're calling me a liar. I am not "merely assuming that it works", I actually tested it to the point of controlling the exact bytes that the server sent to the client using a hand-constructed HTTP response and then pointing Chrome at that server. > For Google to overturn their decision … I just looked into the specific behavior here. Here's what I found: * If you point Chrome at localhost, it includes "br" in the Accept-Encoding header. * If you point Chrome at some other domain using HTTP, it does not include "br" in the Accept-Encoding header. * Either way, if the server actually returns a Content-Encoding of "br", Chrome will respect it. So basically, Chrome always supports Brotli-encoded responses. However, it only requests Brotli over HTTPS and doesn't request it over HTTP, and the only reason for this distinction is to avoid middleware servers from mucking with Brotli-encoded pages that they don't understand.

mmstick 9y ago
No, No, and No. Google engineers have repeatedly declared that Brotli requires HTTPS, because they do not allow it's use of HTTP. You cannot use Brotli over HTTP. You are merely assuming that you can. I am stating that you are lying because you can't have it both ways -- either Google engineers are lying about what their software does, or you are lying about what their software does. It states right there on both of the pages from Google that I linked to you. Brotli will not work without HTTPS. I should know as that's one of the main reasons why I moved to implement HTTPS. It's right there in my latest article on my website before I posted it here. Brotli does not work without HTTPS. Enable HTTPS and pages decode. Switch to HTTP and they do not decode. End of story. You're not very bright to continue arguing against this.
- eridius 9y ago
  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.

rhblake 9y ago

So lemme try to clear this up. You are right in that brotli decoding is only supposed to work in secure contexts (so technically not just HTTPS, btw -- localhost is also considered a secure context, see https://bugs.chromium.org/p/chromium/issues/detail?id=624426 https://bugs.chromium.org/p/chromium/issues/detail?id=624426). Eridius is right in that it currently does work over insecure HTTP in Chrome, as confirmed in this open bug: https://bugs.chromium.org/p/chromium/issues/detail?id=579606 https://bugs.chromium.org/p/chromium/issues/detail?id=579606 -- in which one Chromium dev comments "Decoding brotli even if it isn't requested is both bug and feature. It allows developers to test brotli without setting up https serving." Seems like they concluded that it is indeed a bug, however. Reality and specifications often diverge... (I do think not supporting gzip is absolutely bizarre, but that's another issue.)