I'm not sure what made me think a mere 404 would stop the chap fetching my MetaFilter feed every half hour with no conditional GETs, the URL he's fetching for the referrer (!!), and "-" for a user agent. If he's using a homebrewed client that doesn't do conditional GETs, there's only a slim chance he gives a shit about the status code. He's probably trying to parse my 404 page as RSS.
So along with that spammer, the cold, and some other things, the tht.net Ottawan 134.22.33.32 has made My List.
Comments
comment
Heh, I at least had the decency to test my client on my own feed until I included status code checking and conditional GET. And, my UserAgent string had a meaningful value with a URL on it…
comment
If you’re using apache, try the following configuration directive:
deny from 134.22.33.32
That should get them to go away.
comment
Testing on my feed would be OK even, but there’s no excuse for no user-agent etc when he’s pounding every half hour for weeks now. That’s just bad form.
Thanks, Tony. I should probably set up a valid RSS feed with a message policy rules (#1 being “These are for my use so I’ll do whatever I want”), and redirect to that instead of 404ing or denying. But I may be lazy and just deny from, I don’t know.
comment
you’re stuck with them. i’m still getting requests from a server at purdue that has been being fed a steady diet of 403s, 404s, and bogus feeds since before october 2001.
(yes, i’ve tried contacting him, to no avail.)
then there’s the radio 7 and 8 clients still plinking away at feeds that have been returning 404s nearly as long….
comment
You have been enrolled in the daily newletter.
To unsubsribe, please send an e-mail to court_harkness@ocdsb.edu.on.ca, with a subject of “unsubscribe”.