[supermatt]

Is this a case of Cloudflare not honouring/forwarding the content-encoding header?

Maybe there is a limitation in the way their caching works that it cant differentiate between different encodings, and therefore just requests and caches the most commonly supported encoding?

Why would this be different over https? Why isn't https == http + s? When did that break, and why did we let it?

If we don't want doubly-compressed content (for security/superior compression/whatever), surely it should be up to the browser not to request that encoding, rather than baking it in at some other layer?

[zaarn]

Like with most other newer web features, browsers largely only allow them with HTTPS to A) push for more HTTPS adoption and also B) ensure that proxies can handle upgrades via ALPN and h2 Negotiations.

Brotli and h2 both will break a lot of proxies in the wild, as well as a bunch of web clients. Moonchild/The Palemoon Team do say that the browsers aren't supported by Google/MS/Apple/Moz but the reality is that while those entities do not support those browsers, Cloudflare does.

So from Cloudflare's perspective, the clients they support are likely to break, especially if they might have more middleboxes. Why would they then enable this feature if that is the case?

Moonchild on the other hand seems to want to make a conspiracy out of it.

[supermatt]

I think I simply dont understand what this is all about.

As I understood, this is about CONTENT ENCODING using brotli - i.e. the http response message body is encoded via brotli. Why would this be any different to any other encoding on its impact on proxies?

Of course, brotli compression for the TRANSPORT is another thing. I appreciate that there may be some (non-transparent) proxies, IDS, etc that may choke - but thats not what the author seems concerned with.

It sounds as if cloudflare have disabled brotli content encoding (but just for http?), and are using brotli compressed transport incompatibilities (if you consider not being able to snoop on TLS an incompatibility) as the reason for doing so. The two are completely different things, no?

[zaarn]

No this is very much about brotli transport compression, the original post mentions this more than once. I am actually not aware of any single image format that has widespread brotli content compression support (which will probably not be very useful either as most image compression methods use more domain specific algorithms).

[supermatt]

The original post doesnt mention it at all, it talks about files being compressed for transfer (but no specifics on the implementation).

There is no transport compression/encoding in HTTP. There is transfer-encoding (which is hop-to-hop) and content-encoding (which is e2e). Both only compress the message body.

It seems you may be confusing content-encoding (e.g. gzip - the message-body encoding) and content-type (e.g. image/jpg - the "domain specific compression" you mention).

[zaarn]

There is no transport compression in HTTP? Have you ever heard of Content-Encoding? You seem to be under the impression that this is somehow not a transport compression in some way (it is).

Either way, a brotli encoded HTTP body will cause several issues with proxies and middleboxes, multiple of which have been mentioned in by Cloudflare in their email response.

[supermatt]

> There is no transport compression in HTTP? Have you ever heard of Content-Encoding? You seem to be under the impression that this is somehow not a transport compression in some way (it is).

HTTP is TRANSFER, not TRANSPORT. It is an OSI layer 7 protocol. Transport compression (in TLS) occurs at a different layer (OSI layer 5, the session layer).

Of course i have heard of content encoding - i literally stated it in nearly all of my comments to you.

I also said there is a difference between TRANSFER-encoding (which is a choice of middleboxes) and CONTENT-encoding (which is a choice of client) - and that its not clear from the author which they were talking about.

> Either way, a brotli encoded HTTP body will cause several issues with proxies and middleboxes

Lets be clear - by proxies, you mean non-transparent proxies, and by middleboxes you are talking about deep packet inspection, because nothing else could possibly have a problem with the content encoding as they wouldn't even be looking at it.

This isnt cloudflares "problem" to fix.

Im of the opinion that this was a BREACH mitigation and cloudflare accidentaly applied it to http instead of https, as given their position of trust, they surely wouldnt be assisting other actors with content filtering/inspection...