Change:
A CONNECT request in HTTP/3 functions in the same manner as in HTTP/2.  The request MUST be formatted as described in HTTP2, Section 8.3.  A CONNECT request that does not conform to these <del> restrictions is malformed.  The request stream MUST NOT be closed at the end of the request. </del> <ins> restrictions is malformed (see malformed).  The request stream MUST NOT be closed at the end of the request. </ins> A proxy that supports CONNECT establishes a TCP connection (RFC0793) to the server identified in the ":authority" pseudo-header field.

Discussion:
by importing the RFC7540 malformed request/response text. This section is general enough, it doesn't appear to have much in the way of difference between HTTP/2 and HTTP/3. Are there things we should trim out, or conditions that we need to spell out in more detail?
This issues arises from some off-list discussion on how to build up a header list, and who is responsible for validating the result. The conclusion is that the application is responsible for doing so. In HTTP/2, RFC 7540 section 8.1.2.6 explains how an endpoint should handle malformed requests or responses. There is no explicit link to this in H3, only implicitly via references to topics in 8.1.2.*. However, I think some of that guidance is not applicable: the one that sticks out is this: if the value of a content-length header field does not equal the sum of the DATA frame payload lengths that form the body.
Some further info. In H2, malformed request/response causes a stream error of type PROTOCOLERROR. The H3 draft says: No single mapping. See new HTTPMALFORMEDFRAME error codes defined in Section 8.1. But errors in the category of malformed request/response may not caused by a problem with the frames themselves. Fortunately, we have H3 HTTPGENERALPROTOCOLERROR, which seems like the correct thing to use in this case. But nowhere in the draft is this ever referred to, so its easy to miss.
FRAME related errors are defined at the end of S8.1. However that is going to change due to
Nice catch! I think I'd prefer using HTTPGENERALPROTOCOLERROR or an error code just for this purpose rather than HTTPMALFORMEDFRAME, because this is a framing error in the HTTP semantic layer, rather than an error in a HTTP/3 frame. The issue with using HTTPMALFORMEDFRAME becomes most apparent when the request body is shorter than the sum of DATA frames, and if there is a trailer. Then, the error will be detected when seeing the HEADERS frame. It would be strange to report the issue as HTTPMALFORMEDFRAME(HEADERS) (because it's not an issue with the HEADERS frame), or as HTTPMALFORMED_FRAME(DATA) (because none of the DATA frames that the client sent was malformed.

^^ this comment is about an endpoint abruptly closing a stream rather than an endpoint detecting the peer abruptly closing a stream. Taking back the comment, as I think it deserves a separate issue.
Another error that we saw a lot in the early days of H2 deployment was headers fields using mixed-case capitalization. This cannot be attributed to a malformed H3 frame. I really hope this class of error has been shaken out of systems by now but you never know.
NAME Agreed. I think using HTTPGENERALPROTOCOL_ERROR as a catch-all error code when the peer does something stupid makes sense. After all, that's what we did in H2 and IMO it works well.
I think this falls under the umbrella of making sure RFC7540 content is referenced / restated appropriately in an H3 world.
Maybe it's worth noting that HTTPGENERALPROTOCOLERROR is the error that a proxy is expected to send when upstream resets a HTTP message (e.g., h1 connection being closed in middle of a T-E chunk, receiving RSTSTREAM on a h2 stream). We could have an error code dedicated to that, but H2 has not had one and therefore I do not think there's a strong necessity to have a dedicated codepoint.
Discussed in London; restate them with care.