Original text:
delimiters could be used to cause recipients to incorrectly interpret a message, which could be exploited by an attacker.  An intermediary can reject fields that contain invalid field names or values for other reasons, in particular those that do not conform to the HTTP ABNF grammar from HTTP.  Intermediaries that do not perform

Reviewer comments:
It's going to happen anyway, but we can at least warn people. This doesn't specify what validation is necessary in any detail (that is somewhat involved), it only notes that simple concatenation is almost certainly not secure.
OK that's fine by me. At least they're warned, and those who want to know more will easily find info on the subject, including these conversations. Thank you Martin!
Before we definitely forget about it, could we please have a consideration for that one: URL There is nothing in H2 that prevents pseudo headers from being abused, and it's suggested that they have to be reassembled to make the whole request line, that is usually parsed later to extract the relevant parts, leading to the trouble reported in the portswigger article. And semantics only apply to the recomposed parts, which is too late. I would really like that we suggest controls there so that future implementations do not get caught by this uncovered area, and the comment above proposes the minimalist controls that protect against such attacks.
Willy, this document is now through IESG evaluation and is about to go to the RFC Editor. Adding substantial new text with requirements would require going back to the working group.
Sorry for letting that comment pass at the time NAME It's a reasonable request, but I don't think that we can go as far as specifying specific validation rules. URIs are just too complicated for that. I suggest that we add a special note to which already talks about how intermediaries might be forced to pass on bad stuff. See .
NAME I understand and your approach looks reasonable, many thanks! I've added a tiny comment so that we don't forget to mention ":method" that was also severely abused there, and it's OK for me. NAME I'm not trying to perform substantial changes but have been trying to reload that one over the last 6 months so that we don't miss it. It has been the main cause of generalized vulnerabilities coming from word-for-word implementation of the spec into code, the least we can do is warn implementers.
LGTM.

Revised text:
delimiters could be used to cause recipients to incorrectly interpret a message, which could be exploited by an attacker. <ins> HttpHeaders does not include specific rules for validation of pseudo- header fields.  If the values of these fields are used, additional validation is necessary.  This is particularly important where , , and are combined to form a single URI string (RFC3986).  Similar problems might occur when that URI or just are combined with to construct a request line (as in HTTP11).  Simple concatenation is not secure unless the input values are fully validated. </ins> An intermediary can reject fields that contain invalid field names or values for other reasons, in particular those that do not conform to the HTTP ABNF grammar from HTTP.  Intermediaries that do not perform