4 ms·

I also wonder how these requests "beat the shit out of the web server." It's requesting the feed and the favicon, both of which could be cached by a CDN. Even i

by yosefk 2y ago

I also wonder how these requests "beat the shit out of the web server." It's requesting the feed and the favicon, both of which could be cached by a CDN. Even if they aren't, how much traffic are you gonna see from this compared to some other page trending on HN? Wasteful, sure, but hardly that big a deal

fnord123 2y ago
404s don't get cached. At least I don't configure anything to cache them.
- yosefk 2y ago
  404s have got to be very cheap to serve
  - bandrami 2y ago
    But they aren't always!
  - chiph 2y ago
    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.
    - fnord123 2y ago
      If the CDN returns a 404 or the origin server, then your satellite phone is still waiting.
- theginger 2y ago
  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.
- JimDabell 2y ago
  > 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 https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4
EdwardDiego 2y ago
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)
- yosefk 2y ago
  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.
- mcculley 2y ago
  Why would the issue be “on iOS”? The renderer has nothing to do with how pages are fetched.
  - EdwardDiego 2y ago
    Because Apple.
  - jampekka 2y ago
    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.
cess11 2y ago
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".
smolder 2y ago
> 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.
- yosefk 2y ago
  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
  - theshrike79 2y ago
    But if clients were considerate, we wouldn't need to waste electricity and work hours to run CDNs?
    - yosefk 2y ago
      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.
      - archerx 2y ago
        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.
  - schiffern 2y ago
    >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.
tristan9 2y ago
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.

by yosefk 2y ago

fnord123 2y ago

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

yosefk 2y ago
404s have got to be very cheap to serve
- bandrami 2y ago
  But they aren't always!
- chiph 2y ago
  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.
  - fnord123 2y ago
    If the CDN returns a 404 or the origin server, then your satellite phone is still waiting.
theginger 2y ago
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.
JimDabell 2y ago
> 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 https://datatracker.ietf.org/doc/html/rfc7231#section-6.5.4

EdwardDiego 2y ago

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)

yosefk 2y ago
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.
mcculley 2y ago
Why would the issue be “on iOS”? The renderer has nothing to do with how pages are fetched.
- EdwardDiego 2y ago
  Because Apple.
- jampekka 2y ago
  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.

cess11 2y ago

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

smolder 2y ago

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

yosefk 2y ago
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
- theshrike79 2y ago
  But if clients were considerate, we wouldn't need to waste electricity and work hours to run CDNs?
  - yosefk 2y ago
    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.
    - archerx 2y ago
      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.
- schiffern 2y ago
  >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.

tristan9 2y ago

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.