Hey there,
often I have some problems in my watchdog messages that can not be reproduced in certain browsers.
For example some browsers may search for a "favicon.ico" file in the document root of a domain other don't. But those who do cause 404 errors.
Another use-case would be bots like search engine bots that try to guess URLs based on a pattern that is usually present on the site, which would also cause 404 errors.
There are dozens of other use-cases where a user agent is helpful.
So I wrote a module that would add the user agent to the dblog watchdog entries, which is not that hard, but would cause a lot of database overhead, because it needs an additional two queries per dblog write (select and update).
Also it is not a suitable solution for the syslog module, which would not benefit of a change like this.
So my suggestion is, that we would include the user agent in the core watchdog() function or, to make this whole thing even more open and spare issues like this in the future, make the $log_entry array alterable.
I know that there are risks in the second part, because those altering functions could cause an endless loop if poorly implemented. Also the data that is altered needs to be stored somewhere in the database with the message itself. This is easily implemented if you write your own module, but not so easy when just altering the log entry.
Anyway. I just wanted to throw the second part in there.
My main concern is about putting the user agent in the watchdog $log_entry array from core by default.
I will provide the module that DOES NOT harm the core in any way, so you can have a quick look over what needs to be done to the database etc. in an abstract way.
If there are supporters to this idea out there, I am more than happy to add a core patch.
Thanks
func0der