You repeatedly posted uncivilly in these comments. That's a bannable offense on HN, so please don't do it again, regardless of how wrong you think others are.
Completely lost track of what thread I was reading.
One of these years we might implement a "More" link at the bottom of threads so you have to go to a second page to see them at all.
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.
> 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.
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.
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.
You had to go out of your way to break support for these browsers. Literally every HTTP package (including Rocket) out of the box handles uncompressed responses. You had to modify it to add always-on Brotli encoding.
> I do not support non-SSL HTTP connections.
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.
> Naturally. I would prefer to not have anyone using these tools on my server.
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.
Why?
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.
> What does matter is that my website only supports the HTTPS protocol
No, that has literally no bearing on this discussion about your use of Brotli encoding. You're weirdly fixated with this, but it's completely irrelevant.
> This is nothing more than pure trolling.
Do you normally go out of your way to insult people who are trying to have a discussion with you? Because that's what calling someone a troll is.
> All major web browsers support Brotli over HTTPS
Why doesn't Safari count in your eyes as a major browser? Or perhaps more interestingly, why doesn't iOS Safari count? Are you really ok with your site not working for 100% of iOS users?
> 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.
Why do I have to keep repeating this? HTTPS has literally nothing to do with this discussion. You keep bringing it up over and over again as if it's somehow meaningful, but all it tells me is that you literally have no idea what you're talking about.
> One of the major reasons for me moving my website to HTTPS is so that I could use Brotli compression.
Why do you care so much about this particular compression format?
> Otherwise, Firefox and Chrome will merely get a content encoding error page because br is an unknown encoding format when using HTTP!
You clearly did not test this, because Chrome interprets Brotli responses just fine over HTTP. I wager Firefox does too, but I'm not about to install Firefox just to test.
> You're wrong, and Google engineers are right. End of story.
Google engineers are right, but you are not right. You don't understand what the Google engineers are saying. The link you provided specifically has to do with the Accept-Encoding header and not Brotli support as a whole.
> My target audience consists of Linux users using either Chrome or Firefox.
I still don't understand why you're intentionally breaking the open web. It makes no sense.
> No matter how many times I explain things to you, you never seem to get it through your head.
You should try actually listening. You keep explaining things that are factually wrong or completely irrelevant. You seem to not actually understand HTTP, HTTPS, Content-Encodings, or even the idea of the open web in general. And you're going out of your way to break 99% of tools out there for no discernible reason. Why do you love Brotli so much that you're willing to break HTTP just to use it?
This is the sort of argument that gets a few combatants hot and bothered and clogs up the site with tedium for everyone else. We ban accounts that do this, so please make sure it doesn't happen again. HN threads are for good conversation, and there's no worse conversation than this kind of bickering.
I really do not appreciate you continually calling me a liar (since I've told you in no uncertain terms that I personally have tested this behavior), especially since all you're doing is an appeal to authority ("Google engineers!") based on a misunderstanding of the issue at hand. You keep claiming you have "evidence", but all your "evidence" proves is that you need to work on your reading comprehension skills, because those pages do not say what you think they say.
> You are basically calling Google and each of these authors that I've linked as liars
Let me try this again:
YOU DO NOT UNDERSTAND THIS ISSUE. YOU DO NOT UNDERSTAND HOW CONTENT ENCODINGS WORK OR WHAT EFFECT HTTPS HAS ON BROTLI. I AM NOT CALLING THEM LIARS, I AM CALLING YOU INCREDIBLY IGNORANT.
I am done with this conversation. I am not going to respond to any more of your comments. You don't understand basically any part of what's going on here, but you think you do and you won't even acknowledge the possibility that you are wrong. You're also misinterpreting nearly everything I say, because you're not actually reading my damn comments, you're just skimming them looking for things you can argue against. Case in point, your sentence that starts with "First you said it was 40%"; I was talking about tools that speak HTTP, which was extremely clearly from context, and you're completely misinterpreting that as browsers, and what's more you're even putting words in my mouth (literally nowhere did I say 40%).
That is a serious breach of HN's civility rule and the sort of thing we ban people for. When someone is provocatively repeating wrong statements (or appears to be) and is getting increasingly rude, the way to deal with that is not to lose your own cool, it's to realize that there's no win in this and just leave it.
A.k.a. don't feed the trolls, it takes two to tango, two wrongs don't make a right, and sundry other things our mothers told us.
You are, in fact, right. But I advise you to read about HTTPS here, so you can more clearly understand the points others are making: https://en.wikipedia.org/wiki/HTTPS.
I also don't depend on my blog for food. But I do care and if this were a customer project or something commercial you'd be dead in the water. That's a friendly way of saying that your opinion on what is 'standard' really doesn't count for much with me. You've polluted this thread with I don't know how many comments essentially shouting down each and every patient and restrained effort to teach you something but you won't take a hint.
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.
Eh, maybe in some segments, but I don't think that's the majority culture. See https://github.com/rust-lang/rfcs/pull/1985 for something extremely relevant to the discussion here, heh.
wget and curl both also fail to decompress your site's contents.
Same problem in netsurf, lynx, and links.
> wget and curl both also fail to decompress your site's contents.
I'd consider this a good thing, actually.
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.
> 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.
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, I just get redirected to 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` 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.
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.
> 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.
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.
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).
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 -- 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.)
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.
> 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.
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?
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.
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?
I am using Firefox 53.02 on Linux, and my browser is sending this request header:
Accept-Encoding: gzip, deflate, br
As far as I know Firefox fully supports brotli compression. Any idea what is wrong?
That's utter nonsense.
I think you're mistaken "de-facto standard" for "standard". They are not the same thing, and whether brotli actually is a de-facto standard is debatable, but it's not the standard.
It's perfectly acceptable to do whatever you want with your own web stack and application. You wouldn't be getting much pushback if you simply justified it as "It's what I want to do", but you are providing evidence that is factually incorrect, where no evidence is really required.
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.
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.
The current release of Firefox is only 53.0.2. If you need 52 to view a site, you're overdoing the new features.