We're leaving Cloudflare – here's why – Pale Moon(forum.palemoon.org) |
We're leaving Cloudflare – here's why – Pale Moon(forum.palemoon.org) |
Unfortunately, Cloudfare sides with Firefox and Chrome and does not offer Brotli on HTTP, citing old studies of proxies breaking when exposed to Brotli. They are also telling the author to go away in corporate-speak. The author, however, is unsatisfied and asks:
> What is the real (undisclosed to me) reason they won't consider even the possibility of Brotli being enabled for clients who support it? ... I can only conclude there's some agenda here that I'm being kept in the dark about...
In an internal study (in an enterprise level) and assuming this is HTTP/1.1, that some proxies will either cache only brotli and made it inaccesible to gzip-only clients (even when you bothered with Vary, because they're plain broken in that regard) or just barf with it and time-out not only that particular request but crash a proxy.
The problem for large-scale deployment is that there are transparent proxies in Timbuktu (literally) since data is not cheap there, they need to use HTTP proxies to compress that, not to mention dial-up users in the US! (Good luck, Verizon!)
Or is Moonchild suggesting that Cloudflare is specifically trying to damage Pale Moon by not supporting its unique feature of Brotli over HTTP? That seems unlikely, insofar as it would require them to have an opinion one way or the other about a browser that nobody uses.
Sounds to me like they overestimate they own importance to CF a bit.
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?
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.
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?
Nothing to see here.
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).
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.
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...
It is very clear, no reason to be rude.
>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).
People still believe that the world can be neatly divided into 7 to 8 boxes? Incredible (spoiler alert, modern HTTP in form of HTTP/3 is also Transport and Transfer, OSI Model is outdated). In a more serious maner, this is pendantic at best, HTTP's Content-Encoding is a transport compression, plain and simple, unless you worship the things that OSI made (in which case, have fun with X.200 I guess).
>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.
No, I'm talking about things like caching proxies like they are in common use in places that are bandwidth starved or in literally any serious corporate setting.
And yes, this is very much Cloudflare's problem to fix, because the very people that pay them to be their CDN are the people who deploy those middle boxes that break everything. These aren't "deep packet inspection", most of the times it's a forked and patched Squid Proxy.
Squid Proxy very much looks at the encoding because you can in fact configure it to decompress content or compress content regardless of what the server actually sent as well as saving compressed contents to disk.
As other people in this post have pointed out, if you even allow Brotli over HTTP, a lot of middleboxes will serve this brotli compressed content to all clients, regardless of compatibility. Even if you set Vary: Content Encoding.
If Cloudflare allowed this to break then A) paying customers would tell them it's broken and to fix it and B) they'd loose traffic from people unwilling to surf on cloudflare through their proxy.
>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...
That seems very far fetched indeed, in which case I hope you have proof that this is a mitigation for BREACH applied to plaintext HTTP?
Its not - feel free to quote a single line from that article that talks about whether they are talking about transfer encoding or content encoding.
Im not sure what you find rude about it? The caps were for emphasis. No offense intended...
> People still believe that the world can be neatly divided into 7 to 8 boxes?
You are the one wanting to redefine what transport means.
> the very people that pay them to be their CDN are the people who deploy those middle boxes that break everything
Brotli compression is a switch in CF. You can turn it on and off. Default on for free/pro and off for business/enterprise.
Further digging into CFs behaviour reveals: "The Accept-Encoding header is not respected and will be removed.". It appears they decide what to compress based on UA. Again, this doesnt sound like any upstream middlebox protection, as they strip the header anyway - i.e. it never gets forwarded to origin, so its got nothing to do with upstream provider.
> Squid Proxy very much looks at the encoding
Point me at the issue in squid where it cant handle an unknown encoding.
> I hope you have proof that this is a mitigation for BREACH applied to plaintext HTTP
The primary mitigation for BREACH is to disable content-encoding when using TLS. As I mentioned, it could be they have applied this mitigation in reverse, to http instead of https. http://www.breachattack.com/#mitigations
Most browsers won't offer Brotli, hence UA Analysis is more reliable.
>Point me at the issue in squid where it cant handle an unknown encoding.
Not necessarily squid itself, but i know plenty of middleware boxes that have these issues, in part they are based on squid. Sophos is an example if you run an older box.
> it could be they have applied this mitigation in reverse, to http instead of https. http://www.breachattack.com/#mitigations
But where is proof of that
>You are the one wanting to redefine what transport means.
Not really, you're the one wanting to put the world into 7 boxes.
>Its not - feel free to quote a single line from that article that talks about whether they are talking about transfer encoding or content encoding.
Look for "How does CF handle Brotli?" then read the paragraph after.
>Im not sure what you find rude about it?
Your response was condescending at best.
>Again, this doesnt sound like any upstream middlebox protection, as they strip the header anyway - i.e. it never gets forwarded to origin, so its got nothing to do with upstream provider.
The middlebox will foward the UA in almost all cases, so from CF's perspective, a middlebox will look like a normal user agent with possible Brotli capabilities.
I think you're confusing middleboxes and proxies with the reverse proxy people commonly put behind Cloudflare here, which while technically a middlebox is rarely called that.
- You think UA is more reliable than accept-encoding? wtf.
- I ask to show me the so-called issues with squid, and you cant.
- You ask me to prove this isnt a BREACH mitigation implemented incorrectly - im not a CF employee. Are you?
- OSI levels are a thing that professionals use to communicate about what we are discussing here. If you cant accept that maybe you dont belong on the discussion?
- ask you to quote EXACTLY where it says about transfer vs content encoding, and you cant.