I've noticed the message logged:
error in /includes/database.mysql.inc on line 172
As the request URL was absolutely normal, and a page displayed properly when I've checked it (without any error logged), I've checked the Apache access log. I've found out the requested page seems to be served OK (code 200).
I suspect the user agent part to be a culprit - it contains a backslash (which MySQL doesn't swallow just like that):
"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; TE\x8a)"
Is Drupal code doing anything to carry backslashes properly to MySQL queries? I see the backslash is not a problem in a search string, but what about any other part of the URL request?
To generalize a bit this issue - I am facing MySQL errors also when some browsers supply weird URLs (which are somehow improperly combined existing links with extra characters or strings mixed into them). I believe a non-existing URL report shall be the right response in such cases, and not MySQL error (which means the code execution was broken at that point). So, I believe some much more robust filtering shall be done on browser requests, before any string is supplied to the query - to ensure it can be exectuted properly (can be without results, of course, but it has to be executed without an error).
Back to the primary issue (bad user agent strings) - I've noticed such user agent strings have been creating problems in browscap module in the past. I've also posted an issue in January 2008 about: http://drupal.org/node/207264. Unfortunately, it seems noone carries about (no feedback), so I've simply changed the code of that module, to replace a single backslash with a double one before any query is executed. After that, no errors were reported (but the string is saved only up to a letter before the first backslash, so this doesn't seem to be enough...).
Maybe such backslash is not allowed, but it would probably still be good to have a code ready not to throw out the error (and, probably stop the code processing at this query). Maybe just a warning about the improper string is enough. And - more important - Drupal code shall not break at this query.
Comments
Comment #1
luti commentedI've found out how to (easily) reproduce this issue.
Please take a look at Browser strings not properly saved to a database - comment #5.