Code change:
MUST NOT forward fields that contain any of the values that are listed as prohibited above. <del> A recipient MAY treat a message that contains a field name or value that includes other characters disallowed by HTTP and HTTP as malformed. When a request message violates one of the requirements above, it SHOULD be responded to using the 400 (Bad Request) status code (HTTP) before the stream is reset, unless a more suitable status code is defined, or the status code cannot be sent (e.g., because the error occurs in a trailer field). Note that field values that are not valid according to the definition of the corresponding field do not cause a request to be malformed; the requirements above only apply to the generic syntax for field values as defined in HTTP. </del> <ins> When a request message violates one of these requirements, an implementation SHOULD generate a HTTP, unless a more suitable status code is defined or the status code cannot be sent (e.g., because the error occurs in a trailer field). </ins> 8.2.2.

Related discussion:
text: I take it that you consider RFC7540 failed because of URL which ultimately references URL These indicate that there are cases of CTL characters in field values observed in the wild. The response has been to relax the validation on fields so much that now security problems have been created. I think this is because the minimal validation approach is essentially trying to be secure with a black list (in this case a list of known bad characters). It is far more secure to use a white list approach (i.e what is the minimal character set required to carry the HTTP semantic ). I don't really understand why no attempt was made to enforce the previous specification - I really hope it was not because of who was violating. But if enforcing the spec is seen as impossible, then rather than just leave the validity of fields somewhat undefined, surely a better approach would have been to make some explicit exclusions to allow just the needed control characters in field values. Or perhaps field names must be valid HTTP field names (or psuedo and lowercase), but h2 is more relaxed on field values? Deserting the field and not actually precisely defining what is valid just seams like an inviation to create more special cases and more unforseen security problems.
The real reason for this situation is that we all know that what is extracted from H2 then HPACK will need further processing and that this processing may already be fooled by the contents extracted from there. In addition, H2 being a standard multiplexed protocol on top of TCP is abused by some not really interested in the HTTP aspect of it (e.g. URL) , putting intermediaries at risk of breakage and giving them even more motivation for dropping essential controls and becoming insecure. While I would prefer a wording directly referencing the HTTP spec, like Martin I'm convinced that some will simply not even read it. So I think the proposed addition here can be welcome provided that it does not use the terms "valid" or anything else that might make implementations think "OK that's sufficient", and that presenting the root cause and the risk remains useful to convince those who are hesitating (or at least give them good arguments for not disabling the tests). Let's try again: It's not far from what Martin wrote in the last update, it just tries to better present the context and mention that this has to be done before HTTP parsing. And I'd like to use for treat as malformed.