Reconciling HTTP/2 and HTTP/3 malformedness rules with what implementations actually do

RFC9113 (HTTP/2) and RFC9114 (HTTP/3) both consider a message to be malformed
if it has any of the following:

- A field value with an invalid character.
- A field value with leading and/or trailing whitespace.
- Other characteristics not relevant here.

However, the handling of malformed field values varies widely among implementations:

1. Browsers only consider NUL, CR, and LF to be invalid field value characters.
   They do not allow sending messages with leading or trailing whitespace in a
   field value.  They do allow scripts to send messages with other CTRLs in a
   field value.
2. HAProxy strips leading and trailing whitespace and only considers
   NUL, CR, and LF to be invalid field value characters.
3. NGINX preserves leading and trailing whitespace and only considers
   NUL, CR, and LF to be invalid field value characters.
4. H2O and Varnish both perform strict validation,
   but H2O returns a 400 error instead of a stream error.
5. nghttp2 performs strict validation by default,
   but this can be relaxed to some degree by user callbacks.
6. nghttp3 silently discards a field if the value is malformed.

I think 1, 2, 4, and 5 should be permitted, but 3 and 6 should not be.
Text like the following could make sense.

> Implementations MUST NOT send a message with leading and/or trailing LWS in a field value.
> If such a message is received, implementations MUST either strip the leading and/or
> trailing LWS before doing any other processing, or else treat the entire message as malformed.
> Implementations MUST NOT discard the field value or preserve the leading and/or trailing LWS.
> 
> Implementations MUST NOT send a message with NUL, CR, or LF in a field value.
> A message with NUL, CR, or LF in a field value MUST be treated as malformed.
> 
> Implementations SHOULD NOT send a message with other CTRLs in a field value.
> Implementations that receive such a message MUST either treat the entire message as malformed,
> or treat the CTRLs as ordinary characters.  Implementations MUST NOT silently discard the
> field or replace the CTRLs with SP.
> 
> Clients that receive a malformed message MUST send a stream error.
> Servers that receive a malformed message MUST send a stream error
> or a 400 response.

The last paragraph would have the appropriate version-specific stream error added
before inclusion in the next version of the specs or in an errata.
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)