That would entirely defeat the purpose of cloudflare's DDoS protections.

Yeah, I imagine it would. I can invalidate the cache myself, but it would not make sense for a user to do so.

generally, adding random query params like ?1, ?2, ?12345 helps with the default settings of including that in the cache key.

that will also work in this instance.

you won't however see it slowly send the response as you do on http://trombone.zapto.org/, as cloudflare seems to block until it received the full response from the backend.

You're not wrong, but all of that behavior is configurable so may work on some sites and not others. The account owner can tell cloudflare whether to consider query params different or the same for cache hit puproses. You can also configure whether cloudflare streams/buffers (although some of it does require the enterprise plan).

No affiliation with cloudflare other than I use them for several sites.

indeed, hence

> helps with the default settings of including that in the cache key

I didn't know about response streaming being configurable, it seems to be enabled by default and configurable for enterprise customers: https://support.cloudflare.com/hc/en-us/articles/206049798-S...

I assume due to the (relatively) small response size of this page it buffers regardless.

If you want to visit the page directly without CloudFlare, go to http://trombone.zapto.org instead.

Nice! Thanks for serving me. It was snappier than expected.

Somehow getting the IP address of the server (in this case 174...*) would enable you to connect directly. Websites, such as crimeflare.org crawled the net to gather those addresses, probably by scanning, but the mentioned site was shut down as it seems.

A site that really wants Cloudflare's protection would ignore all traffic that doesn't come from Cloudflare though. In practice, many origins probably aren't locked down in this fashion.