- From: Martin Thomson <mt@lowentropy.net>
- Date: Mon, 23 Aug 2021 17:49:23 +1000
- To: "Willy Tarreau" <w@1wt.eu>
- Cc: ietf-http-wg@w3.org
Thanks Willy,
> However the next paragraph mentioning this does still maintain some confusion:
>
> A field name MUST NOT contain characters in the ranges 0x00-0x20,
> 0x41-0x5A, or 0x7F-0xFF
> (all ranges inclusive). This limits field names to visible ASCII
> characters, other than
> ASCII SP (0x20) and uppercase characters ('A' to 'Z', ASCII 0x41 to
> 0x5a).
>
> Especially this last sentence which *seems* to endorse the use of such
> other characters for header field names, thus contradicting the first points.
Yeah, that's a mistake. How about:
> This specifically excludes all non-visible ASCII characters, ASCII SP (0x20), and uppercase characters ('A' to 'Z', ASCII 0x41 to 0x5a).
I don't think that we need to combine paragraphs as you suggest. The point is that these are *extra* checks that apply even if you are only forwarding messages. (RFC 7540 basically said what you suggest and it turned out that no one paid any attention to it.)
> An HTTP/2 recipient that receives a field name containing a character
> in the range 0x00-0x20, 0x41-0x51, or 0x7F-0xFF (all ranges inclusive),
> or a field value containing a character 0x00 (NUL), 0x0A (LF), 0x0D (CR)
> MAY treat this as a connection error of type PROTOCOL_ERROR.
A connection error is something we already permit. It's just indirect. You have to follow the chain from here to the definition of malformed and then to stream errors, but it's there.
Received on Monday, 23 August 2021 07:50:01 UTC