5 ms·

Naturally. Since moving to HTTPS, I have dropped support for gzip, and I will not be re-adding it. There is no benefit in continuing to retain legacy gzip suppo

Naturally. Since moving to HTTPS, I have dropped support for gzip, and I will not be re-adding it. There is no benefit in continuing to retain legacy gzip support. Brotli can compress and decode faster than gzip, and it produces smaller file sizes. That Safari still doesn't support Brotli isn't my problem. It's Apple's problem. I'm not going to be yet another site that condones stagnant progress when everyone else has already supported it for more than a year. More sites should drop gzip support to force Apple to add support for Brotli in Safari.

jononor 9y ago
You just broke your site for 40% of the web. http://caniuse.com/#feat=brotli http://caniuse.com/#feat=brotli
kcorbitt 9y ago
If I were focused so unapologetically on purity over pragmatism at the expense of playing nice with the wider web ecosystem, I would perhaps think twice before holding my site up as a positive example of the state of web development with Rust. You may end up doing more harm than good in the PR department. :)
- mmstick 9y ago
  I see it as more of an Apple problem. Everyone else's web browser works fine, but Apple's doesn't. The main reason why companies like Apple still don't support Brotli even though the competition has supported it for more than a year now is because too many sites are focused on carrying legacy support for unsupported platforms like Safari. If more sites dropped support for legacy software, Apple would be forced to implement Brotli support and then everyone could benefit.
  - gue5t 9y ago
    GNOME's, Xfce's, suckless', and many other web browsers are based on Webkit (WebKit2GTK+ or other ports) as well, and as far as I know none of them yet support brotli. wget and curl both also fail to decompress your site's contents. Same problem in netsurf, lynx, and links.
    - mmstick 9y ago
      This is because I don't have a HTTP website! The website is HTTPS-exclusive. If your tool does not support HTTPS, it will certainly not work on my website. > wget and curl both also fail to decompress your site's contents. I'd consider this a good thing, actually.
      - deleted 9y ago
        [deleted]
      - thristian 9y ago
        All the tools mentioned in the comment you're responding to support HTTPS just fine.
  - eridius 9y ago
    Have you filed a bug report asking Apple to support Brotli (https://bugreport.apple.com https://bugreport.apple.com)? And it's not just Safari. I think it's safe to say the overwhelming majority of software that issues HTTP requests does not support Brotli. And you're also not following the HTTP spec. Safari sends the Accept-Encoding header with a value of "gzip, deflate". If you're unwilling to support either of those, and unwilling to return an uncompressed response, then you SHOULD return a 406 (Not Acceptable) instead of just blindly returning Brotli-encoded data to a client that doesn't understand it.
    - mmstick 9y ago
      I don't use Apple products, nor am I user of Safari. It's not in my interest to request for Brotli support in products that I do not use. > I think it's safe to say the overwhelming majority of software that issues HTTP requests does not support Brotli. And you're also not following the HTTP spec. Again, I do not support HTTP! The website is HTTPS-exclusive. HTTP is basically a legacy protocol at this point. Every website should be encrypted. > If you're unwilling to support either of those, and unwilling to return an uncompressed response, then you SHOULD return a 406 (Not Acceptable) instead of just blindly returning Brotli-encoded data to a client that doesn't understand it. I may do just that then.
      - eridius 9y ago
        > It's not in my interest to request for Brotli support in products that I do not use. You've already positioned yourself as trying to take a principled stand against software that doesn't support Brotli in the hopes of convincing the software authors to add support for Brotli. Now you're saying you don't care whether software you don't use supports Brotli. These two positions contradict each other, and if you really don't care about software you don't use, then why are you so dead set against serving up uncompressed content to that software? > Again, I do not support HTTP! You completely missed the point. I know your site doesn't support HTTP. But HTTPS is generally understood to be part of the umbrella of "HTTP". It is in fact literally the same protocol (well, for HTTP/1.1; HTTP/2 is a brand new protocol and irrelevant for this discussion), just wrapped in SSL. > I may do just that then. Just so we're clear, your site currently does not work, and will continue to not work, with tools like `curl` or `wget`, or nearly all other non-browser tools people have written.
  - flukus 9y ago
    > even though the competition has supported it for more than a year now is because too many sites are focused on carrying legacy support for unsupported platforms like Safari. That says it all really. Unfortunately it also seems to be a common attitude in the rust community. Something doesn't become legacy just because a newer option has been available for a year.
    - steveklabnik 9y ago
      > Unfortunately it also seems to be a common attitude in the rust community. Eh, maybe in some segments, but I don't think that's the majority culture. See https://github.com/rust-lang/rfcs/pull/1985 https://github.com/rust-lang/rfcs/pull/1985 for something extremely relevant to the discussion here, heh.
eridius 9y ago
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.
      - 9y ago

jononor 9y ago

You just broke your site for 40% of the web. http://caniuse.com/#feat=brotli http://caniuse.com/#feat=brotli

kcorbitt 9y ago

If I were focused so unapologetically on purity over pragmatism at the expense of playing nice with the wider web ecosystem, I would perhaps think twice before holding my site up as a positive example of the state of web development with Rust. You may end up doing more harm than good in the PR department. :)

mmstick 9y ago
I see it as more of an Apple problem. Everyone else's web browser works fine, but Apple's doesn't. The main reason why companies like Apple still don't support Brotli even though the competition has supported it for more than a year now is because too many sites are focused on carrying legacy support for unsupported platforms like Safari. If more sites dropped support for legacy software, Apple would be forced to implement Brotli support and then everyone could benefit.
- gue5t 9y ago
  GNOME's, Xfce's, suckless', and many other web browsers are based on Webkit (WebKit2GTK+ or other ports) as well, and as far as I know none of them yet support brotli. wget and curl both also fail to decompress your site's contents. Same problem in netsurf, lynx, and links.
  - mmstick 9y ago
    This is because I don't have a HTTP website! The website is HTTPS-exclusive. If your tool does not support HTTPS, it will certainly not work on my website. > wget and curl both also fail to decompress your site's contents. I'd consider this a good thing, actually.
    - deleted 9y ago
      [deleted]
    - thristian 9y ago
      All the tools mentioned in the comment you're responding to support HTTPS just fine.
- eridius 9y ago
  Have you filed a bug report asking Apple to support Brotli (https://bugreport.apple.com https://bugreport.apple.com)? And it's not just Safari. I think it's safe to say the overwhelming majority of software that issues HTTP requests does not support Brotli. And you're also not following the HTTP spec. Safari sends the Accept-Encoding header with a value of "gzip, deflate". If you're unwilling to support either of those, and unwilling to return an uncompressed response, then you SHOULD return a 406 (Not Acceptable) instead of just blindly returning Brotli-encoded data to a client that doesn't understand it.
  - mmstick 9y ago
    I don't use Apple products, nor am I user of Safari. It's not in my interest to request for Brotli support in products that I do not use. > I think it's safe to say the overwhelming majority of software that issues HTTP requests does not support Brotli. And you're also not following the HTTP spec. Again, I do not support HTTP! The website is HTTPS-exclusive. HTTP is basically a legacy protocol at this point. Every website should be encrypted. > If you're unwilling to support either of those, and unwilling to return an uncompressed response, then you SHOULD return a 406 (Not Acceptable) instead of just blindly returning Brotli-encoded data to a client that doesn't understand it. I may do just that then.
    - eridius 9y ago
      > It's not in my interest to request for Brotli support in products that I do not use. You've already positioned yourself as trying to take a principled stand against software that doesn't support Brotli in the hopes of convincing the software authors to add support for Brotli. Now you're saying you don't care whether software you don't use supports Brotli. These two positions contradict each other, and if you really don't care about software you don't use, then why are you so dead set against serving up uncompressed content to that software? > Again, I do not support HTTP! You completely missed the point. I know your site doesn't support HTTP. But HTTPS is generally understood to be part of the umbrella of "HTTP". It is in fact literally the same protocol (well, for HTTP/1.1; HTTP/2 is a brand new protocol and irrelevant for this discussion), just wrapped in SSL. > I may do just that then. Just so we're clear, your site currently does not work, and will continue to not work, with tools like `curl` or `wget`, or nearly all other non-browser tools people have written.
- flukus 9y ago
  > even though the competition has supported it for more than a year now is because too many sites are focused on carrying legacy support for unsupported platforms like Safari. That says it all really. Unfortunately it also seems to be a common attitude in the rust community. Something doesn't become legacy just because a newer option has been available for a year.
  - steveklabnik 9y ago
    > Unfortunately it also seems to be a common attitude in the rust community. Eh, maybe in some segments, but I don't think that's the majority culture. See https://github.com/rust-lang/rfcs/pull/1985 https://github.com/rust-lang/rfcs/pull/1985 for something extremely relevant to the discussion here, heh.

eridius 9y ago

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.
    - 9y ago