Clarify the definition of things that make messages malformed

[kazuho]

Section 4.1.3 of HTTP draft states that a malformed request or response is one that is an otherwise valid sequence of frames but is invalid due to the presence of extraneous frames, prohibited header fields, the absence of mandatory header fields, or the inclusion of uppercase header field names.

Based on the discussion we have been having in #3300, I think we agree that we mean the connection-specific header fields designated in section 8.1.2.2 of RFC 7540.

But in the HTTP/3 draft, I can neither find the corresponding text, or a reference to that part of RFC 7540.

I think we should clarify what the term means.

[MikeBishop]

In Section 4.1.1:

The restrictions on the use of pseudo-header fields in Section 8.1.2 of [HTTP2] also apply to HTTP/3.

This also feeds into #3264, which suggests those prohibitions should be local to the document.

[kazuho]

connection-specific header fields (e.g., transfer-encoding) are not pseudo-header fields.

[MikeBishop]

Fair enough. I think I'd like to generalize this issue:

• Invalid sequences of frames should be connection errors (DATA before HEADERS, multiple non-final HEADERS, possibly multiple trailers modulo Add capability for sending HTTP metadata (trailer fields) in mid-stream #3265)
• Which header fields are prohibited and mandatory needs to be clearly stated; violations of this remain stream errors
• Upper-case field names remain stream errors

Let's make "malformed" more precise, and that should resolve most of our differences on #3300.

[MikeBishop]

@mnot, @larseggert, @LPardue: The fix to this will not be editorial, because it mandates certain things which were stream errors now become connection errors.