On Thu, Dec 22, 2016 at 11:37 AM, Rainer Jung <rainer.j...@kippdata.de> wrote:
> Am 22.12.2016 um 18:25 schrieb William A Rowe Jr: > >> On Thu, Dec 22, 2016 at 9:29 AM, Eric Covener <cove...@gmail.com >> <mailto:cove...@gmail.com>> wrote: >> >> I think the log severity changes below could use some eyes, especially >> in context of 2.2. Are these lowered because they're redundant? I >> haven't yet looked. >> >> I am tempted to leave the old severities for 2.2 and wait and see if >> it's confusing in 2.4 (should not have to enable DEBUG to see the >> cause of a 400 error) >> >> >> Log severity is lowered because successfully throwing off a (generally >> deliberately) bad request is of no interest to an operator at loglevel >> error/warn, any more than any successful request is of interest. >> >> This is just log pollution. There is no action for the operator to take. >> > > Hmmm, but if it isn't about a deliberately bad request but a bad client, > the admin could consider setting "HttpProtocolOptions Unsafe" (and now get > what he asked for. I must admit, I didn't check whether the log lines in > question are in code areas which are controlled by HttpProtocolOptions or > not. > That's true. However, every admin/operator knows that if the app dev team or users are complaining that the request doesn't work, the first thing any admin does is enable loglevel debug to see what's going on. The CTL's aren't override-able (see the security reports 2.4 detailed description) by our group concensus, and my UnsafeWhitespace proposal was rejected. But there is still information at debug level to know what sort of problem occurred without breaking out wireshark first. Once that is sorted, it's still noise and needs to be disabled again. The broken clients will be the very odd exception, not a rule.
