--- Comment #12 from ---
Re Jay Freeman/#9:

> If a user wanted to mess with me, they'd just start requesting 404s off my 
> server until I run out of disk space.

How exactly does the requested patch deny them the ability to do so? Best case
scenario, it slows them down by roughly 30%, unless you omit all 404 requests
from the access log as well.

> In all seriousness: I can't do anything to fix or help a 404.

You're approaching this thing from a very narrow minded point of view. For you,
404 errors are apparently forced on your server from someone on the outside,
possibly even with ill intent.

>From my perspective, 404 errors happen when I link to files that don't exist,
and so the huge majority of 404 errors I'm seeing are caused by *me*, until I
fix my site.

I'd agree that the ratio is likely to have changed over time because all kinds
of clients request all kinds of files nowadays that may or may not exist, in
order to provide browser, platform, and crawler dependent content.

> do you actually pay attention to them, and if you do, what do you do when you 
> see them? What is your tactical response to seeing a 404? Does anyone out 
> there actually want this in their logs? :(

Yes, I absolutely do.

Like I said, most of these errors are caused because *I* screwed up (or "my"
web developers/designers etcetera), and thus *I* need to fix them by correcting
broken links/image tags/script sources/background image urls.

404 errors that are caused by outside parties (apple-touch-icon foo and so on),
well, let me just ignore them.

IMHO, a better solution would have been to introduce new log levels, while
making sure that the default behavior remains unchanged; maybe by splitting
errors into error and http_error or some such.

I guess now that the change has been implemented (5 years ago, I know... but I
just came across this for the first time), there's little hope of getting the
previous behavior restored.

Anyway, the lack of documentation just cost me 3 hours of my life, so I'd have
appreciated if this had been reflected in the 2.4 documentation - at first I
honestly thought my recent Debian 8 upgrade had somehow broken Apache's error
logging in a very weird way and checked all kinds of stuff before searching the

Bug report regarding the documentation: [1]


You are receiving this mail because:
You are the assignee for the bug.

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to