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

luti’s picture

Version: 5.7 » 6.14

I've found out how to (easily) reproduce this issue.

Please take a look at Browser strings not properly saved to a database - comment #5.

Status: Active » Closed (outdated)

Automatically closed because Drupal 6 is no longer supported. If the issue verifiably applies to later versions, please reopen with details and update the version.