Lighttpd

Everything that calls log_error() in lighttpd gets sent to the error log.
If the error log is sent to syslog, then everything sent to the error log is sent with level LOG_ERR.

This is long-standing behavior.

While you are correct that lighttpd could be more precise in labelling the log messages with different severities, this is not currently done. It is not like there is a mistake in one or two messages, but rather that the levels are not marked on each message and the levels are not passed as a parameter to the logger.

Therefore, while you are correct that this is a limitation in lighttpd, I may end up closing this issue as "Won't Fix".

Separately, for mod_accesslog, LOG_INFO is used by default, and that is configurable with accesslog.syslog-level.

Therefore, while you are correct that this is a limitation in lighttpd, I may end up closing this issue as "Won't Fix".

Does that mean you’d accept a patch, if at some point I were to get around to writing one?

Does that mean you’d accept a patch, if at some point I were to get around to writing one?

Probably not. I am not convinced of the value of such a patch that could touch over 1000 lines of code.

lighttpd1.4/src$ grep log_error *.c | wc -l
1037

I do appreciate that you asked the question.

Various approaches to passing syslog message priority resulted in large increases in code size.

There are some experimental commits on my development branch
https://git.lighttpd.net/lighttpd/lighttpd1.4/src/branch/personal/gstrauss/master

If you find the time and have the inclination, you're welcome to submit patches for discussion which update various call sites e.g. from log_error() to log_debug() and from log_error_multiline() to log_debug_multiline().

Making changes to call sites is a behavior change and would have to be announced with the next lighttpd release. Patches will be considered.

If you find the time and have the inclination, you're welcome to submit patches for discussion which update various call sites e.g. from log_error() to log_debug() and from log_error_multiline() to log_debug_multiline().

I see you added macros for the other levels as well, not just error and debug. Should I use those macros as well, if it seems appropriate for a given call site?

How do you prefer I send those patches? I looked around a bit but wasn’t able to find documentation for contributors—for example, do you want patches by e-mail, attached to this ticket, in a Git repo, or something else? Any preference on formatting of commit messages? That kind of thing.

Minimum requirement is a unified diff, which may be attached here or in the lighttpd Development forum.
You may alternatively submit a pull request to https://github.com/lighttpd/lighttpd1.4/

I suggest you start with a small, focused patch, such as changing appropriate calls from log_error_multiline() to log_debug_multiline().

Correct. Three of the five calls are controlled by debug directives.
How would you like to be credited in the commit? 'Hawk777' or something else?
I typically add a "(thx Hawk777)" in commits with contributor patches.

though `log-request-header-on-error` could be argued to be higher than that.

No. That is a stretch and a poor hand-waving argument. On the other hand, a more solid argument grounded in reality is the observation that `debug.log-request-header-on-error` controls optional debug trace and is named as such. Rejected request headers are rejected regardless of whether or not additional debug trace is sent to the logs. The debug trace is optional.

Please stop hand-waving stupid stuff. Make a proper defense of your statements or avoid sharing your hot takes and groundless opinions. (They are groundless because you did not provide any grounding.)

How would you like to be credited in the commit? 'Hawk777' or something else? I typically add a "(thx Hawk777)" in commits with contributor patches.

That’s fine, thanks.

No. That is a stretch and a poor hand-waving argument. On the other hand, a more solid argument grounded in reality is the observation that `debug.log-request-header-on-error` controls optional debug trace and is named as such. Rejected request headers are rejected regardless of whether or not additional debug trace is sent to the logs. The debug trace is optional.

I agree it’s under the category of “debug”; that having been said, it’s also something that only applies when there’s an error (albeit an external one). Would you mind clarifying what your position is on whether a failure of something outside Lighttpd itself (HTTP client, CGI process, HTTP proxy backend server, or whatever) is considered an error or not for logging purposes? Personally I’d rather not have an error reported every time some random network scanner decides to send a funny-looking request which my web server rejects; if the attack it was probing for fails, then it’s just noise. It sounds like you probably agree, but I’d like to be sure you want that as an overall rule rather than in this one specific case (should I find other log messages elsewhere that are not controlled by something with `debug` in the name, for example).

Would you mind clarifying what your position is on whether a failure of something outside Lighttpd itself (HTTP client, CGI process, HTTP proxy backend server, or whatever) is considered an error or not for logging purposes?

Personally I’d rather not have an error reported every time some random network scanner decides to send a funny-looking request which my web server rejects; if the attack it was probing for fails, then it’s just noise. It sounds like you probably agree, but I’d like to be sure you want that as an overall rule rather than in this one specific case (should I find other log messages elsewhere that are not controlled by something with `debug` in the name, for example).

I'm not sure you've gotten the point yet. I am wholly uninterested in EVERYTHING from you which contains "my opinion" or "personally" or anything like it because you have been inept at providing any real observations or grounding to back up those opinions. Hand-waving theoreticals are theoreticals.

In that vein, what problem(s) are you trying to solve? lighttpd is not a new piece of software. "What the code does" is exactly the behavior that answers your question "What should it do?". You have not identified a specific error message or messages which bother you (besides those behind debug directives, which have already been addressed).

If you have new demonstrable examples of noise in your log from scanners, and you can intelligently make a case WITHOUT injecting any of your worthless opinions, then we can have a conversation about it. lighttpd has in the past put some logging behind config options, e.g. debug.log-ssl-noise, so a conversation is possible. To set expectations, what WILL NOT happen is unnecessary changes to match your personal choices for syslog. If you are incapable of filtering your syslog queries, then I suggesting learning how to do so.

If there is something in lighttpd logging that bothers you, but that lighttpd developers (me) do not want to change in lighttpd, then one possible solution for you is to use a piped-logger server.errorlog = "|/path/to/your/custom/filter.py" and to filter some messages and map others to your desired syslog level, and then syslog them from your custom filter.py program. Please don't waste my time if you can not articulate -- omitting opinions -- why a specific error message is causing actual, measurable impact in the real world, not just in your head.

You have not identified a specific error message or messages which bother you (besides those behind debug directives, which have already been addressed).

I actually did, in the very first message of this ticket: “server started” is not an error. If you agree, then let’s limit the scope of this ticket to that specific message and avoid considering my opinion on any others. If you disagree, then I guess drop this altogether.

let's limit the scope of this ticket

This ticket is already closed and resolved, marked fixed. It is obvious to me that you haven't bothered to look at commits on the lighttpd git master branch that were pushed over a week ago, and yet you continue talking, so here, I am going to stop.

Thank you for that change.