I’ve been in touch with CloudFlare support directly about this already and was recommended I go here to have it discussed.
The issue is that Brotli isn’t being used over http connections, only https connections, and (re-)encoding on the CF edge only occurs if a browser/client is using TLS to connect.
While I am aware that 5 years ago when Brotli was first introduced for web traffic there was an interop issue with some middleware boxes trying to use shared compression tables (SDCH) and not being smart enough to recognize that responses were already compressed with Brotli (or any other non-deflate/gzip encoding), and https being pretty much passthrough for those boxes because it was end to end encrypted, that has long since been deprecated.
Of course in that situation the decision was made to only enable Brotli over https to prevent breakage, but it has since also been used as a vessel to disadvantage plain connections “to further the encrypted web”.
While I have no issue with promoting encryption where desired, I do think there’s no reason whatsoever to continue denying people using http the denser compression and bandwidth savings that Brotli offers.
In my talks with support that went into some depth (thanks , Gabe!) some concerns were brought up by CF engineers but I don’t really see an issue with any of them. I’d like to engage all you fine folks here and see what you think, and hopefully the CF engineers will also take notice and revise their position on it.
- There was concern about compression side-channel attacks if Brotli would be enabled on http alongside https traffic, naming specifically CRIME and BREACH. compression side-channel attacks like CRIME and BREACH are equally usable (provided the server-side is set up in a vulnerable way that makes this a concern) regardless of which compression method is being used, so Brotli would take the exact same position as gzip, deflate, or any other compression method, due to how these attacks work by measuring compressed stream sizes for injected data. There is literally no greater or smaller security risk involved in providing brotli-compressed content over HTTP than providing gzipped content over HTTP (which you do). See  for a white paper outlining these attacks and the general nature of any compressed response being usable. Any compression, even the most rudimentary decently-effective compression that results in differing compressed sizes for guessed data, may enable exploitation of vulnerable servers. Please note that for these attacks to work, some prerequisites must also be met, like being able to inject data in a user’s requests consistently (both http and https!), and having critical and session-unique data being served by the server in an equally consistent manner. A plaintext MitM will certainly not allow this, and forward secrecy cipher suites on the TLS connection to be attacked will also make this considerably harder.
- Brotli is also not significantly different from other compression techniques. Brotli is a general-purpose, lossless data compression algorithm that uses a variant of the LZ77 algorithm, Huffman coding, and second-order context modelling. Zip is also LZ77 based with Huffman encoding and the resulting streams are very similar, albeit that because of the context modelling (leveraged during compression) the data will be more densely packed in the case of Brotli. 
- I’ve also been in touch with Mozilla about this (who were one of the entities pushing Google-sourced Brotli to the web) actually echoing other users who have asked about this. However, Mozilla has clearly indicated that its current continued use of Brotli only over https is very much a way to “prefer advancing [the] encrypted web” by explicitly not providing users any benefit of dense compression when transferred over http. Mozilla has also categorically refused to reconsider their approach for this reason, while users have requested this more than once. There’s even an open bug (submitted by a Mozilla employee, at that) for enabling it in secure context (which would be secure context over plaintext connections) with patch attached that has gone stale. 
- enabling this on CloudFlare’s end will not change anything for end users who use Chrome or Firefox with default settings for content-encoding, exactly because it, like TLS, needs client-server agreement on what is encoded with which compression. As long as clients (browsers) are not indicating they accept Brotli encoding in their request (which is currently the case for Chrome-based browsers and Firefox over http) they will never negotiate the Brotli compression method as acceptable, and nothing will change. But, by refusing the option on CF’s side, CF is enforcing the smallest common set and preventing more efficiency (and bandwidth reduction) in clients that do accept it, as, no matter what a client indicates it supports, it will never be used if there is no agreement from the server side to use br.
Despite these points there still seems to be a lot of resistance to enabling Brotli over http, which I am trying to understand. There is no security issue with doing so that I am aware of (no more than having gzip/deflate enabled which is the case, anyway!), there will be no impact for mainstream browsers because both server and client must agree to use it, and it just seems to be very much arbitrary at this point.
Please help me understand this reluctance to have better performance and efficiency over http.
Thanks for reading to the end.
 (Breach attack (PDF))
 RFC 7932, see e.g. the heavy reliance in  and that it is a direct
 RFC 1951
 Bugzilla bug 1719155
 Bugzilla bug 1670675
 Bugzilla bug 1675054