Would I be right in guessing that we're looking at a well-built security system responding to high page load?
Saying the page doesn't exist in these types of situations is interesting. Users consider 404s permanent, so some proportion is unlikely to come back. Furthermore, because each user is hitting the page individually, there's going to be very little out-of-band "no it doesn't work", so it won't reduce server load by much.
From a security standpoint, if high load like this is causing "lp0 on fire"-type issues, a generic 404 may be the correct answer, depending on the situation. A 404 is quite generic, but I'm sure it could still leak useful information depending on the scenario.
Whatever's going on, hearing what actually happened would be very cool (and educational, most people here are Web developers!).
It seems to be working again. Sorry about the snafu. I've been exchanging emails with the team on the hosting side, but I don't yet have info on what happened.
In case it's useful, some of the page resources were 503ing/404ing before:
http://i.imgur.com/5JUyphf.png (the intermixed connection_refused errors are from my /etc/hosts blocking)
Would I be right in guessing that we're looking at a well-built security system responding to high page load?
Saying the page doesn't exist in these types of situations is interesting. Users consider 404s permanent, so some proportion is unlikely to come back. Furthermore, because each user is hitting the page individually, there's going to be very little out-of-band "no it doesn't work", so it won't reduce server load by much.
From a security standpoint, if high load like this is causing "lp0 on fire"-type issues, a generic 404 may be the correct answer, depending on the situation. A 404 is quite generic, but I'm sure it could still leak useful information depending on the scenario.
Whatever's going on, hearing what actually happened would be very cool (and educational, most people here are Web developers!).