Code change:
8.2.1. <del> HPACK is capable of carrying field names or values that are not valid in HTTP.  Though HPACK can carry any octet, fields are not valid in the following cases: </del> <ins> The definitions of field names and values in HTTP prohibits some characters that HPACK might be able to convey.  HTTP/2 implementations SHOULD validate field names and values according to their definitions in Sections HTTP and HTTP respectively and treat messages that contain prohibited characters as malformed. Failure to validate fields can be exploited for request smuggling attacks.  In particular, unvalidated fields might enable attacks when messages are forwarded using HTTP11, where characters such as CR and COLON are used as delimiters.  Implementations that do not fully validate field names and values MUST perform the following minimal validation: </ins> A request or response that contains a field that violates any of these conditions MUST be treated as malformed.  In particular, an

Related discussion:
text: This just moves the reference to the canonical definition of what is valid up to the top of the section. That's the canonical text. This emphasizes the point that HTTP/2 is placing additional requirements on endpoints with respect to validation. This does not really in the sense that it leaves validation of DQUOTE and friends to the core semantics implementations. Note that any "MAY" requirement for rejecting a messaging can have the desired effect on those generating those messages: if an endpoint puts DQUOTE in a field name, that message will have little hope of being successfully handled.
My 2 cents: it seems that there's disagreement about whether the validity requirements from the core specs need to be repeated. Of course, DRY. Semantics currently says: The issue here is that H/2 actually extends that ABNF (without doing that as ABNF), which makes the link somewhat weak. Maybe formally (==ABNF) defining "h2-fieldname" as "lowercase-http-fieldname / h2-pseudofield" would be helpful.
So the proposal would be:
Julian, YES PLEASE for ABNF (yeah I know that is editorial, but it makes it so much more concise and exact). I think everybody agrees that a h2 impl MUST NOT generate invalid HTTP fields. The differences appear on the receiving side as the current document allows that h2 impls MAY accept some invalid HTTP fields. I've never understood the use-case for this? cheers
Well, AFAIU, we do not have a hard requirement on recipients in the base spec (and HTTP/1 either): So this seems consistent with what the base spec says.
I have no objection to adding ABNF to define H2’s fields. I would say that we should keep the prose, as the prose does a good job of expressing the why of our choices: for example, explaining the expectations around lowercase field names. However, I agree with NAME and my past self that we do not need add a “MUST validate” section.
Thanks Martin. I'm having a bit of difficulty parsing this sentence: "These checks are the minimum necessary to avoid accepting messages that might avoid security checks". Maybe "These checks are the minimum necessary to forward or process the message as an HTTP message" ? Also "A recipient can treat a message ..." why not "s/can/SHOULD" ?