5 ms·

It's not user-hostile at all. It is quite simple. I don't want to implement gzip support, and I definitely don't want uncompressed content. You can't demand me

It's not user-hostile at all. It is quite simple. I don't want to implement gzip support, and I definitely don't want uncompressed content. You can't demand me to implement what I don't want to implement for my website. You are not my target audience (gzip users, IE users, Safari users). > And it's not just Safari. All sorts of tools that support HTTP don't support Brotli. Case in point, I ran `curl` against your page and got garbage back. My website does not support HTTP. HTTP is basically a legacy protocol at this point. My website is HTTPS-exclusive. It does not listen on port 80. That Brotli doesn't work through HTTP is not surprising, given that HTTPS support is a base requirement for Brotli support.

eridius 9y ago
From your last paragraph I question whether you really understand anything you're being told here. Yes, I said HTTP instead of HTTPS, but that wasn't meant to signify that I was using unsecured HTTP, since HTTPS is supported virtually everywhere and generally understood to be a part of HTTP. More specifically, if I actually try and access http://mmstick.tk http://mmstick.tk, I just get redirected to https://mmstick.tk https://mmstick.tk anyway, without having a content body, so it's not even possible to get Brotli-encoded data out of your server over HTTP. And if I run `curl https://mmstick.tk` https://mmstick.tk` then I get garbage, which was the whole point of that sentence and what you still haven't even addressed. Also, how can HTTPS possibly be a requirement for Brotli? Brotli is a compression format, it doesn't care what the medium of transmission is, and it works just fine over HTTP. It just won't work with your site over HTTP because your site doesn't serve any content over HTTP.
- mmstick 9y ago
  I'm not sure where your confusion is. It doesn't matter that HTTPS is an encrypted form of HTTP. I do not support HTTP, which means that I do not support HTTP without encryption! End of story. Attempting to access the site via HTTP will merely redirect you to the HTTPS service. Nothing is being hosted on the HTTP service. When you reach the HTTPS service, your browser will receive a HSTS header that will cause your web browser to automatically direct to the HTTPS server and not touch HTTP at all for future requests, ever. Nor can your connection be downgraded to HTTP. > Also, how can HTTPS possibly be a requirement for Brotli? Brotli is a compression format, it doesn't care what the medium of transmission is, and it works just fine over HTTP. It just won't work with your site over HTTP because your site doesn't serve any content over HTTP. Tell that to Google, Mozilla, and Microsoft. You cannot use Brotli compression over HTTP. Only when you are using the HTTPS protocol can you use Brotli. And in general, if you support HTTPS and are using an update browser, you more than likely already have support for Brotli today.
  - eridius 9y ago
    Your use of HTTPS is completely irrelevant here, but I've already addressed that in the other thread (https://news.ycombinator.com/item?id=14345695 https://news.ycombinator.com/item?id=14345695). > You cannot use Brotli compression over HTTP. 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. My best guess here is you've confused HTTP/2 (which requires SSL) with Brotli encoding.
    - mmstick 9y ago
      > 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

From your last paragraph I question whether you really understand anything you're being told here. Yes, I said HTTP instead of HTTPS, but that wasn't meant to signify that I was using unsecured HTTP, since HTTPS is supported virtually everywhere and generally understood to be a part of HTTP. More specifically, if I actually try and access http://mmstick.tk http://mmstick.tk, I just get redirected to https://mmstick.tk https://mmstick.tk anyway, without having a content body, so it's not even possible to get Brotli-encoded data out of your server over HTTP. And if I run `curl https://mmstick.tk` https://mmstick.tk` then I get garbage, which was the whole point of that sentence and what you still haven't even addressed. Also, how can HTTPS possibly be a requirement for Brotli? Brotli is a compression format, it doesn't care what the medium of transmission is, and it works just fine over HTTP. It just won't work with your site over HTTP because your site doesn't serve any content over HTTP.

mmstick 9y ago
I'm not sure where your confusion is. It doesn't matter that HTTPS is an encrypted form of HTTP. I do not support HTTP, which means that I do not support HTTP without encryption! End of story. Attempting to access the site via HTTP will merely redirect you to the HTTPS service. Nothing is being hosted on the HTTP service. When you reach the HTTPS service, your browser will receive a HSTS header that will cause your web browser to automatically direct to the HTTPS server and not touch HTTP at all for future requests, ever. Nor can your connection be downgraded to HTTP. > Also, how can HTTPS possibly be a requirement for Brotli? Brotli is a compression format, it doesn't care what the medium of transmission is, and it works just fine over HTTP. It just won't work with your site over HTTP because your site doesn't serve any content over HTTP. Tell that to Google, Mozilla, and Microsoft. You cannot use Brotli compression over HTTP. Only when you are using the HTTPS protocol can you use Brotli. And in general, if you support HTTPS and are using an update browser, you more than likely already have support for Brotli today.
- eridius 9y ago
  Your use of HTTPS is completely irrelevant here, but I've already addressed that in the other thread (https://news.ycombinator.com/item?id=14345695 https://news.ycombinator.com/item?id=14345695). > You cannot use Brotli compression over HTTP. 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. My best guess here is you've confused HTTP/2 (which requires SSL) with Brotli encoding.
  - mmstick 9y ago
    > 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.