Lighttpd

I should note that obtaining remote IP for these error messages is already reasonably available by enabling high-precision timestamps in error log and access log, and cross-referencing by the high-precision timestamp (+ small delta).
You can log remote IP and potentially other info (e.g. a specific Cookie) in the accesslog.

server.errorlog-high-precision = "enable"

accesslog.format using %D or %{...}t with high-precision specifiers such as one of %{msec}t %{usec}t %{nsec}t %{msec_frac}t %{usec_frac}t %{nsec_frac}t, and prefix %{end:...}t for the ending time of the request instead of the begin time (as the ending time may be closer to the error in the error log).

My feature request concerns the "normal" error messages, not the ones that must be activated explicit (e.g. debug.log-request-header-on-error or debug.log-ssl-noise). I was several times in the situation, that somebody complains about a problem and I see nothing in the logs except an error message, which I cannot assign to this problem without e.g. a client IP.

The remote/client IP is the most important addition, because with this I can identify a request, that needs investigation. The port is not important to me. When the point is reached, that users are authenticated or client certifcates are decoded, then usually all is ok. Especially I'm interested int the very early failures in TLS-connections and the ones that generate a 400 response.

It is NOT a must-have, it is just a wish, and I understand now, that it is not so easy and lightweight as I thought.

• (request.c.278)
• (mod_openssl.c.3247)
• (connections.c.718)

in this order.

Correction: I use debug.log-request-header-on-error = "enable", where some of the error messages above may come from.

• (mod_openssl.c.3247)
• (connections.c.718)

I only want the remote/client IPs for messages, which have no corresponding entry in one of the access logs.

That makes sense.

For established connections, con->dst_addr_buf.ptr is a readily-available formatted string of the remote IP, which might be changed by mod_extforward.

How does the format below look to you, or would you prefer the IP at the beginning? Should I prefix the IP with "(ip:%s)"? (It could also be a unix domain socket, not an IP.) The following patch adds the IP as a suffix since I tend to try to keep existing error strings the way they are since others, such as commercial log aggregators and processors, may have strict string matching to classify and translate errors.

--- a/src/connections.c
+++ b/src/connections.c
@@ -715,10 +715,11 @@ static int connection_handle_read_state(connection * const con)  {
             /* expecting ASCII method beginning with alpha char
              * or HTTP/2 pseudo-header beginning with ':' */
             /*(TLS handshake begins with SYN 0x16 (decimal 22))*/
-            log_error(r->conf.errh, __FILE__, __LINE__, "%s",
+            log_error(r->conf.errh, __FILE__, __LINE__, "%s (%s)",
                       c->mem->ptr[c->offset] == 0x16
                       ? "unexpected TLS ClientHello on clear port" 
-                      : "invalid request-line -> sending Status 400");
+                      : "invalid request-line -> sending Status 400",
+                      con->dst_addr_buf.ptr);
             r->http_status = 400; /* Bad Request */
             r->keep_alive = 0;
             connection_set_state(r, CON_STATE_REQUEST_END);
--- a/src/mod_openssl.c
+++ b/src/mod_openssl.c
@@ -3245,7 +3245,8 @@ connection_read_cq_ssl (connection * const con, chunkqueue * const cq, off_t max
                 }
                 /* get all errors from the error-queue */
                 log_error(hctx->errh, __FILE__, __LINE__,
-                  "SSL: %d %s", rc, ERR_error_string(ssl_err, NULL));
+                  "SSL: %d %s (%s)", rc, ERR_error_string(ssl_err, NULL),
+                  con->dst_addr_buf.ptr);
             }
             break;
         }

I applied your patches and the format looks good for me, thanks a lot.

• (connections.c.1072) unknown state: 53 272 (this message may have been triggered by tests with ticket #3118)
• (mod_openssl.c.3135) SSL: renegotiation initiated by client, killing connection

(connections.c.1072) unknown state: 53 272 (this message may have been triggered by tests with ticket #3118)

Yeah, that should not happen and was probably memory corruption fixed in #3118

(mod_openssl.c.3135) SSL: renegotiation initiated by client, killing connection

Ok, I guess it is reasonable to consider TLSv1.2 renegotiation attempts as security scans or as attacks.

--- a/src/mod_openssl.c
+++ b/src/mod_openssl.c
@@ -3133,7 +3133,8 @@ connection_read_cq_ssl (connection * const con, chunkqueue * const cq, off_t max
         if (hctx->renegotiations > 1
             && hctx->conf.ssl_disable_client_renegotiation) {
             log_error(hctx->errh, __FILE__, __LINE__,
-              "SSL: renegotiation initiated by client, killing connection");
+              "SSL: renegotiation initiated by client, killing connection (%s)",
+              con->dst_addr_buf.ptr);
             return -1;
         }