characters allowed in field values

[reschke]

https://tools.ietf.org/html/rfc7540#section-10.3:

Similarly, HTTP/2 allows header field values that are not valid.
While most of the values that can be encoded will not alter header
field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII
0xa), and the zero character (NUL, ASCII 0x0) might be exploited by
an attacker if they are translated verbatim. Any request or response
that contains a character not permitted in a header field value MUST
be treated as malformed (Section 8.1.2.6). Valid characters are
defined by the "field-content" ABNF rule in Section 3.2 of [RFC7230].

There are multiple issues here:

• it's confusing to say "HTTP/2 allows" when next they are actually forbidden with a MUST requirement; it might be better to say something like that the wire protocol in theory enables the transmission of these forbidden characters
• this puts a normative requirement on top of the base spec; but so does the revision of the core specs (see field-value production rules out CTL characters, but these are common in the wild http-core#683). We need to make sure that there are no conflicting requirements. It also should be checked whether the currently present requirements are actually implemented in UAs (and if they are not, what could be done about it)

[Lukasa]

It would presumably be more accurate to say that "HPACK allows", right?

[afrind]

HPACK also allows encoding a field line with an empty name. I'm not sure this needs to be mentioned explicitly or not.

[reschke]

HPACK also allows encoding a field line with an empty name.

Well, that's consistent with HTTP/1.1 :-)

[martinthomson]

I hate having to do this, but what is possible and what is permissible need to be more clearly separated.

[martinthomson]

I'm going to tag this as editorial: the possible/permissible split is clearly editorial. And we've decided to depend on the core docs, and whether or not it was clear before what was allowed or not, this is now very crisp in the core semantics. I want to wait until we get #811 in before doing this though.

[martinthomson]

Discussed in the context of leading and trailing whitespace in -semantics. I think that we should be clearer here about a few things:

1. CRLF and NUL are strictly prohibited
2. leading and trailing WS are strictly prohibited
3. Maybe loosen the requirement a little so that it is less strict about adherence to the ABNF

That makes this non-editorial, I think.