7 ms·

I'm not saying you should support gzip. I'm saying you're sending Brotli-encoded data even when the browser doesn't support it, which results in the browser sho

I'm not saying you should support gzip. I'm saying you're sending Brotli-encoded data even when the browser doesn't support it, which results in the browser showing what looks like effectively random bytes. You need to respect the Accept-Encoding header.

mmstick 9y ago
That would require that I cache both a gzip and brotli variant of each page and content that is requested. I see no reason to support gzip just because a single company has refused to implement support for Brotli. Firefox, Chrome and Edge all support Brotli. Safari is the one man out. Apple needs more complaints about the lack of Brotli in Safari. Using Safari? Don't. You have Firefox and Chrome on all of your platforms.
- eridius 9y ago
  This is an incredibly user-hostile attitude. Also, you don't seem to understand. I'm not telling you to support gzip. If the browser doesn't support Brotli, then just send back uncompressed content. 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.
  - mmstick 9y ago
    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.
- sqeaky 9y ago
  What about serving uncompressed content over https? What about serving up an error page when the user's browser odesn't have compressor you support? What about paying attention to web standards? What about people who are stuck with old software for one reason or another?
  - mmstick 9y ago
    > What about serving uncompressed content over https? I have limited bandwidth. I don't want to serve uncompressed content over HTTPS. > What about serving up an error page when the user's browser odesn't have compressor you support? I will do that once I figure out how to get the Request header from Rocket's API. > What about paying attention to web standards? I'm already complying with HTTPS web standards. I'm even pending for the HSTS preload list ( https://hstspreload.org/?domain=mmstick.tk https://hstspreload.org/?domain=mmstick.tk ). > What about people who are stuck with old software for one reason or another? That's their problem, not mine. You shouldn't be using old web browsers and outdated systems on the web. That makes you vulnerable.
    - sqeaky 9y ago
      > That's their problem, not mine. You shouldn't be using old web browsers and outdated systems on the web. That makes you vulnerable. You wouldn't host a page if you didn't want to share its content, doesn't failing to do so make it atleast partially your problem? You are ignoring the list of encodings the client gives you, you are paying attention to some and not all. If we all did the web wouldn't work. Maybe they have good reasons, you aren't them and you don't know their situation. But you have chosen to not share with people with tech older than one year... Step back, and try to take an objective look at this. Do you know what percentage of web browsers actually in use will work? Do you know what percentage of people visiting your page see only gibberish? Finally, Why are so many of your comments in the gray and everyone else's not in the gray? Why do so many of your technical peers disagree with you?

mmstick 9y ago

That would require that I cache both a gzip and brotli variant of each page and content that is requested. I see no reason to support gzip just because a single company has refused to implement support for Brotli. Firefox, Chrome and Edge all support Brotli. Safari is the one man out. Apple needs more complaints about the lack of Brotli in Safari. Using Safari? Don't. You have Firefox and Chrome on all of your platforms.

eridius 9y ago
This is an incredibly user-hostile attitude. Also, you don't seem to understand. I'm not telling you to support gzip. If the browser doesn't support Brotli, then just send back uncompressed content. 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.
- mmstick 9y ago
  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.
sqeaky 9y ago
What about serving uncompressed content over https? What about serving up an error page when the user's browser odesn't have compressor you support? What about paying attention to web standards? What about people who are stuck with old software for one reason or another?
- mmstick 9y ago
  > What about serving uncompressed content over https? I have limited bandwidth. I don't want to serve uncompressed content over HTTPS. > What about serving up an error page when the user's browser odesn't have compressor you support? I will do that once I figure out how to get the Request header from Rocket's API. > What about paying attention to web standards? I'm already complying with HTTPS web standards. I'm even pending for the HSTS preload list ( https://hstspreload.org/?domain=mmstick.tk https://hstspreload.org/?domain=mmstick.tk ). > What about people who are stuck with old software for one reason or another? That's their problem, not mine. You shouldn't be using old web browsers and outdated systems on the web. That makes you vulnerable.
  - sqeaky 9y ago
    > That's their problem, not mine. You shouldn't be using old web browsers and outdated systems on the web. That makes you vulnerable. You wouldn't host a page if you didn't want to share its content, doesn't failing to do so make it atleast partially your problem? You are ignoring the list of encodings the client gives you, you are paying attention to some and not all. If we all did the web wouldn't work. Maybe they have good reasons, you aren't them and you don't know their situation. But you have chosen to not share with people with tech older than one year... Step back, and try to take an objective look at this. Do you know what percentage of web browsers actually in use will work? Do you know what percentage of people visiting your page see only gibberish? Finally, Why are so many of your comments in the gray and everyone else's not in the gray? Why do so many of your technical peers disagree with you?