That's an unusual problem. Browsers are normally forgiving with Location: URLs, automatically turning a relative URL into an absolute URL for the current site. However, when provided with an absolute URL to begin with, all browsers are supposed to follow that URL.

I assume your actual go.php code is a long list of if statements for every different m value, what's the scripts default behavior if $_GET['m'] isn't set?

Also, is there a pattern with the user-agent or IP address that generates the 404?

Thanks a lot for a reply.

I do have a line of code that goes to default link in case there is no "m" referral.

IPs are very similar to each other (few pools), most from one state, and all belonging to HUGHES NETWORK SYSTEMS.

All user agents are either MSIE 7.0 or MSIE 6.0.

So there is definitely a clue about client side.

I do track 404s in this way with two different sites, and this happens with one only.

So, it is specific to one site only, and it is also specific to one ISP on a client side.

Still, why?

I’ll dig into logs and search for those IPs to see if they get those links right as well or they always fail.

With a distinct pattern on the client side, this problem is most likely not related to your script.

I lack enough information to say for sure, but you might have a poorly programmed bot (like a downloader) hitting that site. Whomever made it may have just gotten lazy on how to handle Location: URLs and just programmed it to ignore any domain name provided and relativize the link. (I can see this easily, considering the need to be able to handle relative Location: URLs.)

You'd have to look at the behavior of the IP/UA in your log files to judge for yourself if this is the case. I've found most bots (particularly the many poorly programmed ones) are very obviously different than human users.

Another possibility is that there is some plugin/toolbar on that client which makes a separate request to your server and that plugin/toolbar is the poorly programmed culprit.