[thelist] Weird 404s - not from our server

[Paul Cowan]

Hi all,

This is not really an important issue, but I'd love to hear some ideas.

A little while ago, I set up a custom 404 handler in IIS, so that when any
404 error occurs, our development team get emailed:
	- The URL accessed
	- The "MemberID" of the logged-in member
	- Any query parameters
	- Any CGI server variables.
	- etc.

This seems a bit excessive, but it's worth it for the reaction you get when
a webmaster somewhere puts a broken link to our site live, and we email them
within a few minutes pointing out their error... also helps us keep our
internal links tidy, spot missing images, etc.

Anyway, the problem is, ever since inception, we get emails like the
following (this example chosen for its outlandishness):

	[AUTOMATED MESSAGE] A customer tried to access the following page:

	URL Accessed:  http://hardcore.sexplanets.com/buran/t111.jpg
	HTTP Referrer: [Direct Link]
	Member ID:     [NULL]
	Server:        our.server.ip.here
	User IP Info:  some.user.ip.info

	Server Variables:
	=================
	HTTP_ACCEPT:*/*
	HTTP_CONNECTION:keep-alive
	HTTP_HOST:hardcore.sexplanets.com
	HTTP_USER_AGENT:Mozilla/4.75 [en] (Windows 5.0; U)
	HTTP_VIA:some-proxy-server.somewhere.blob
	HTTP_CACHE_CONTROL:public
	HTTP_X_FORWARDED_FOR:some.user.private.ip.here
	... etc ...

(it is not recommended that you visit hardcore.sexplanets.com during working
hours).

So, my question is this: hardcore.sexplanets.com does not resolve to our IP
address. How on earth is our server getting HTTP requests for that site?
This happens moderately often (several times a week), often with multiple
sites in the space of a few minutes. It's possible someone has a dodgy DNS
that is somehow thinking that hardcore.sexplanets.com actually has our IP
address -- but this doesn't seem to fit.

It's not a particular ISP or anything either. My best guess is that the
browser in question has some thread-safety issue, where it mistakenly sends
request from window A (lustily browsing hardcore.sexplanets.com) through to
window B (innocently browsing wishlist.com.au), but it doesn't seem to be
right - we've had requests do this from both NS 4 and IE 5 in the past, so
it's unlikely to be a browser problem.

Any ideas? How would we be getting, from a variety of sources, HTTP requests
which don't even belong to our server?

Help.....

Cheers,

Paul Cowan
wishlist.com.au