404s don't get cached. At least I don't configure anything to cache them.

> A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls

— https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4

This why in a lot of contexts it would be good to at least be micro catching them. If they were cached for 5 seconds it would have covered all subsequent requests.

404s have got to be very cheap to serve

Not when you're on a metered connection, or on a high latency one.

Don't make your customers pay for your sloppy habits is a good policy to have.

If the CDN returns a 404 or the origin server, then your satellite phone is still waiting.

But they aren't always!

Why should you need to provision a CDN when If-Modified-Since / Etags exist?

I get that not every client is well behaved, but you'd hope that Firefox would be, given Mozilla's presence in web standards.

(Which, tbh makes me think this issue is the "on iOS" bit, given it's Firefox. I presume Apple still has their "only Safari's rendering engine" rule in place for... ...reasons)

A CDN caches across users, lowers latency by having servers closer to the user, and lowers the bandwidth your server needs to handle. Cloudflare CDN has a free tier and I assume others do, too, so it's fairly easy to provision.

Why would the issue be “on iOS”? The renderer has nothing to do with how pages are fetched.

They probably have to write a totally different fetching logic for the Safari wrapper. If Apple wasn't as scummy as they are, they would have used the same logic as in other platforms where this problem doesn't seem to exist.

Because Apple.

Pretty weird to think that running a web server also means you should operate "a geographically distributed network of proxy servers and their data centers".

I also think it's pretty weird to defend thoroughly defect software with "waste ful, sure, but hardly that big a deal".

> Wasteful, sure, but hardly that big a deal

This attitude is why so much software is garbage, and why people with limited connections or hardware can't have a good time on the internet.

In this case, using a CDN in front of the server is the thing which would improve things for people with limited bw/hw more quickly and to a greater extent than counting the fetches by Firefox on iOS and calling it out for fetching too much

But if clients were considerate, we wouldn't need to waste electricity and work hours to run CDNs?

You would want a CDN anyway to cache data across users, on servers close to those users, cutting the time & energy spent to serve the data.

I feel like this is a marketing meme by cdn providers that gets parroted a lot. As someone who has used CDNs vs hosting on the server directly, CDNs are slower to load the images especially when there is a cache miss. The only reason I’m using a cdn is because I need to host 100gb+ images. If it wasn’t for that I wouldn’t use a cdn and get a better experience on the site.

  >In this case, [X] would improve things more quickly than [Y].

Maybe so, but more importantly why are you phrasing this like it's an either/or choice?

"We, the developer community, contain multitudes." Clearly we can (and should) do both.

Besides the obvious benefits at the higher community level of organization, deploying both solutions will result in even less bandwidth and power wasted from this specific bug than using either solution by itself.

Bad take.

I opened the Github issue linked. For us it represented, at times, thousands of requests per second across multiple users. And that was with affected users getting IP-banned temporarily.

Some of which were 404s which you typically absolutely do not want cached. Or 405s (on HEAD /favicon.ico for example). Or 429s. Or 403s.

Browsers are expected to: 1. Use the favicon specified in meta if any (we do have one, /favicon.svg) 2. Respect cache headers (immutable + multi-months max-age) 3. Not make completely random requests to things they should ignore (such as OpenGraph tags)

Yes CDNs do help with these kinds of issues, but they absolutely do not fix them all. Which is why even though we have a pretty damn elaborate setup in that regard we were being annoyed by the issue.

But also Firefox on iOS should be not-completely-broken.