Query string read as part of file name, throwing not found errors

Question

Hi all, I host a number of Web sites under a CF7 installation, Win2003.
One site in particular is throwing not-found errors in response to certain search bot requests.
In the IIS log, I noticed that for these requests, the query part of the URL is part of cs-uri-stem field value, but is not in the cs-uri-query field where it belongs:
cs-uri-stem=                                               /index.cfm?template=24hour5.cfm
cs-uri-query=<blank>
instead of
cs-uri-stem=                                               /index.cfm
cs-uri-query=template=24hour5.cfm
Evidently something somewhere is interpreting the entire URL as a filename, instead of a file name and a query string. When CF tries to locate the file it is throwing a not-found error.
Maybe there is something weird about the question mark, but it looks normal to me.
I can't seem to stop this error, since it is occuring at the OS, IIS, CF or jrun layer. Does anyone have any idea what is going on here, and what I can do about it?
Thanks in advance.
Joe

Answer 1

Hey Reed, thanks for responding.
I have a Cf utility that parses logs, so I modifed it to print out the ASCII codes for each character. They look normal, as far as I can tell. The question mark has a code of 63 which is correct, and no non-alphabetic characters precede or follow.
One interesting thing is that the stem being called is an index.cfm file, and the query string argument happens to be a template name, and it ends in .cfm. That's why it is making it all the way to CF, which chokes on it, instead of IIS logging a 404 error.
Often an identifiable bot is requesting these bad URLs, though I have spotted another request with agent 'Mozilla/4.0.' I suspect that is some kind of automated scan. (I also see other requests with the same agent name, though a different IP, that look like errononeously URL-encoded requests. These get filtered by URLScan.)
I don't know for sure is whether the specific clients that make these bad calls always make them them wrong way. They appear to. Most clients that access the site do so normally.
I wonder if there could be something in the request header, perhaps that instructs IIS to expect a different charset than what is actually used, or something like that.