Previously I was plagued by a number of spurious 404 errors, which had no connection to anything within any of my pages. I eventually bodged it by creating stubs of the files it was trying to access, part of the idea being that if it crashed something I might get a better idea of what it was.
I've just checked this morning and the top two this month (currently 60 hits) are:
/-banner.jpg 60 http://www.project-future.org/
/-box.jpg 60 http://www.project-future.org/
...any ideas what they are? I'm starting to think the rotating banner has freaked out.
Do you have a page with the banner/box in it that doesn't have a proper username set? That's usually what causes that.
EDIT: It's also possible someone's browser whacked out, and didn't properly run the javascript, so it requested bad images.
Quote from: Xepher on April 17, 2009, 02:48:28 PM
Do you have a page with the banner/box in it that doesn't have a proper username set? That's usually what causes that.
EDIT: It's also possible someone's browser whacked out, and didn't properly run the javascript, so it requested bad images.
Here's the fragment handling the banner:
</td><td style="vertical-align: center; width: 300px;"><center>
<script type='text/javascript' src='http://xepher.net/newsbox.js.php?username=project-future&shape=box'></script>
</center></td></tr></table>
EDIT:
....either way, I'm getting many, many more counter hits than 404s so whatever it is seems to be affecting a minority of browser clients.
Why not just code it to always use a default user if there isn't one set?
There actually are "undefined-box.jpg" and "undefined-banner.jpg" files for that exact purpose. They're blank files. Which is why I'm curious how the variable would be actually unset by the browser (rather than just "undefined") and would be requesting stuff to his specific virtual host. All the URL references for the banner images should be to "http://xepher.net/..." itself, and thus logged/404ed under the main logs, not on a particular vserver.