Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We're leaving Cloudflare – here's why – Pale Moon

forum.palemoon.org

Post reply on HN
Print view View original

11–20 of 23 posts

Re: We're leaving Cloudflare – here's why – Pale Moon

#11

Post by supermatt »

zaarn wrote: post #9
supermatt wrote: post #8

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-compress…

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…

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?

Re: We're leaving Cloudflare – here's why – Pale Moon

#12

Post by zxcvbn4038 »

Why go to war over something trivial like this? None of the major browsers support http/2 nor Brotli over plain http connections - if not for COVID they probably wouldn’t support plain http connections at all. They were set to depreciate those but held off at the start of the pandemic because so many government sites were still http only. You have to go with flow sometimes. If you want to ask Cloudflare a favor then not re-compressing my highly optimized zopfli source files with standard gzip would be a good one. Passing through the accept-encoding header so I can send my highly compressed brotli responses instead of them repacking my gzip responses would be another. At least the option to select those behaviors if the mom and pops can’t be trusted to do it right.

Re: We're leaving Cloudflare – here's why – Pale Moon

#13

Post by zaarn »

supermatt wrote: post #11
zaarn wrote: post #9

Earlier quoted context omitted.

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…

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 th…

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).

Re: We're leaving Cloudflare – here's why – Pale Moon

#14

Post by supermatt »

zaarn wrote: post #13
supermatt wrote: post #11

Earlier quoted context omitted.

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 th…

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).

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).

Re: We're leaving Cloudflare – here's why – Pale Moon

#15

Post by NetOpWibby »

EveYoung wrote: post #10
comex wrote: post #7

Earlier quoted context omitted.

And what could that agenda possibly be? That they really like encryption and think everyone should use it? They haven't exactly been shy about telling people that. 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 th…

> We've [...] helped them grow and become known through positive posts, blog entries and the likes. [...] seen/helped them grow to become one of the largest CDNs. Sounds to me like they overestimate they own importance to CF a bit.

Ah, so it’s just a post about some company with a god complex, complaining.

Nothing to see here.

Re: We're leaving Cloudflare – here's why – Pale Moon

#16

Post by NetOpWibby »

theamk wrote: post #2

Summary: the author is worried about Brotli compression (like existing gzip but 20% better) for HTTP protocol. Both Firefox and Chrome require HTTPS for Brotli; but Pale Moon authors disagree and enable Brotli even on plain HTTP connections. 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…

Thanks for saving a click

Re: We're leaving Cloudflare – here's why – Pale Moon

#18

Post by zaarn »

supermatt wrote: post #14
zaarn wrote: post #13

Earlier quoted context omitted.

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).

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…

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.

Re: We're leaving Cloudflare – here's why – Pale Moon

#19

Post by supermatt »

zaarn wrote: post #18
supermatt wrote: post #14

Earlier quoted context omitted.

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…

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.

> 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...

Re: We're leaving Cloudflare – here's why – Pale Moon

#20

Post by zaarn »

supermatt wrote: post #19
zaarn wrote: post #18

Earlier quoted context omitted.

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.

> 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 n…

>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.

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?

Post reply on HN