That's because ESR is a very ancient version of Firefox. Many things don't work on ESR. You need at least Firefox 52.
178 karma · joined December 27, 2016
Actually, if you look at the top level comments that I've made, that's exactly what I said. What I'm getting in response to that is that I'm basically 'breaking the web' because I don't want to comply with sniffing request headers and offering gzip to Apple WebKit users. If I don't care about supporting your web browser, then I don't care about supporting your web browser. You can't make me.
> Also, it should be noted that there is a valid reason to eschew compression for HTTPS on the client side, and that's security. Compression of HTTPS channels opens up the possibility for a few more forms of attack on the encrypted data.
That kind of security isn't a concern to me. Not having compression at all would take a larger toll on my bandwidth, and increase latency of page delivery. Bandwidth isn't free.
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... ).
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-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.
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 ).
> 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.
I did not have to go out of my way to 'break support for these browsers'. All I did was replace the gzip-compression code in my page cacher with brotli-compression code. In other words, I went from always-on Gzip encoding to always-on Brotli encoding! I have never supported serving uncompressed files! The web browsers I care about (Firefox, Chrome) support Brotli, and that's all I care about! There is no purposeful breaking of web browsers. That's just persecution complex talk.
> Why do you keep repeating this? That's completely irrelevant to the discussion at hand. Nothing about this discussion has anything to do with whether or not the HTTP protocol is wrapped in SSL.
You're the one that keeps bringing up that the only difference between HTTP and HTTPS is that HTTPS is HTTPS with SSL. I am merely responding to your comment that your comment about them doesn't matter! What does matter is that my website only supports the HTTPS protocol, not HTTP. The web server only listens on port 443 with TLS enabled.
> So, you want a web site that completely breaks HTTP such that only works with a handful of browsers and doesn't work with the probably tens or hundreds of thousands of pieces of other software that speaks HTTP.
This is nothing more than pure trolling. All major web browsers support Brotli over HTTPS. Apple's WebKit is the only man out, and they are, at best, a minority on the web. Firefox supports it, Chrome supports it, and Edge supports it. Even if Edge didn't support it, the fact that Firefox and Chrome support it is more than enough for me. Other browsers are just bonuses.
Furthermore, yet again, I do not have a HTTP server, so there is no HTTP here to break! HTTPS is implemented to spec, HSTS headers and all! My website is meant to be viewed by people, not machines. In addition, as the web is moving to being HTTPS-exclusive, it's about time that you start getting used to it. You're wasting your time.
I'm not sure where you think the contradiction is. That I do not support web browsers that don't support Brotli should already tell you that I don't care if they support Brotli or not! If there is no support, there is no support! Doesn't effect me.
> 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.
Basically completely irrelevant to what's being discussed here. I do not support non-SSL HTTP connections. That is all!
> 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.
Naturally. I would prefer to not have anyone using these tools on my server.
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.
> 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.
> wget and curl both also fail to decompress your site's contents.
I'd consider this a good thing, actually.
> 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.
The contradiction in your logic here is that if you don't want to handle errors, then don't design your functions to return errors. In addition, many of the larger time game studios write and use their own standard library, so they could devise an efficient 'game stdlib' where they don't have to pay such costs.
> I would love to use Rust in games (I currently work in games) but it's not clear that it would work out.
There are many contradictions in your posts on here.
> stop making grand, unfounded assertions about what Rust is good for
You are basically stating that everything that I have done in Rust is a lie. I will not stand for that.
If the timestamp has expired and a user requests expired content, only then will that page be re-generated, re-compressed and updated. Without this, I would have to re-generate and re-compress the content each time I get a request.