BUG/MEDIUM: h1: always reject the NUL character in header values

Ben Kallus kindly reported that we still hadn't blocked the NUL
character from header values as clarified in RFC9110 and that, even
though there's no known issure related to this, it may one day be
used to construct an attack involving another component.

Actually, both Christopher and I sincerely believed we had done it
prior to releasing 2.9, shame on us for missing that one and thanks
to Ben for the reminder!

The change was applied, it was confirmed to properly reject this NUL
byte from both header and trailer values, and it's still possible to
force it to continue to be supported using the usual pair of unsafe
"option accept-invalid-http-{request|response}" for those who would
like to keep it for whatever reason that wouldn't make sense.

This was tagged medium so that distros also remember to apply it as
a preventive measure.

It should progressively be backported to all versions down to 2.0.

src/h1.c

@@ -947,6 +947,17 @@ int h1_headers_to_hdr_list(char *start, const char *stop,
 			goto http_msg_ood;
 		}
 	http_msg_hdr_val2:
+		if (likely(!*ptr)) {
+			/* RFC9110 clarified that NUL is explicitly forbidden in header values
+			 * (like CR and LF).
+			 */
+			if (h1m->err_pos < -1) { /* PR_O2_REQBUG_OK not set */
+				state = H1_MSG_HDR_VAL;
+				goto http_msg_invalid;
+			}
+			if (h1m->err_pos == -1) /* PR_O2_REQBUG_OK set: just log */
+				h1m->err_pos = ptr - start + skip;
+		}
 		if (likely(!HTTP_IS_CRLF(*ptr)))
 			EAT_AND_JUMP_OR_RETURN(ptr, end, http_msg_hdr_val2, http_msg_ood, state, H1_MSG_HDR_VAL);