Back

@waldoj <confused>Doesn't cURL specify in the request headers what types of compression it accepts? Doesn't Cloudflare obey that?</confused>

@waldoj When I run curl from the command line without --compressed it doesn't specify Accept-Encoding at all, which I believe means the server shouldn't compress? When I run it with --compressed it specifies Accept-Encoding with a specific list of compression algorithms it knows how to handle. Maybe updown.io is using curl wrong?

@jik updown.io is using this:

curl -gkvL4 -b '' -H 'User-Agent: updown.io daemon 2.11' -H 'Accept: */*' -H 'Connection: Close' -H 'Accept-Language: en' -H 'Accept-Encoding: deflate, gzip, br, zstd' -m 30 --connect-timeout 10 --compressed https://www.example.com/

It looks to me like updown.io updated their Accept-Encoding string, but *didn't* update their version of cURL to actually be able to handle Brotli.

@waldoj @jik ok so the issue is nothing to do with cloudflare and rather than updown.io botching it?

@tay @jik I *think* that's right? I am Unhappy about Cloudflare turning on a new form of compression that cannot be turned off unless you give them money, but I don't know enough about Brotli adoption to know if that's fair to criticize them for.

@anildash @waldoj @jik Providing a optimisation to clients that have requested it that has no tangible effect on the data the client actually receives is good, actually.

@tay @waldoj @jik I mean, we have content negotiation specs for that reason, no?

@anildash @waldoj @jik Cloudflare is respecting the Accept-Encoding header sent by updown.io. updown.io is manually specifying Accept-Encoding: br (...), even though the version of curl inuse cannot Accept Encoding br

@tay @waldoj @jik ah, then that’s great and the bug sucks