Re: Permitted characters in HTTP/2 fields

Hey Willy,

On Fri, May 21, 2021, at 02:59, Willy Tarreau wrote:
> I really agree. I don't remember if 0x80 and above are forbidden in H2 but
> I'd personally prefer to block them so that we don't needlessly introduce
> the risk of aliasing due to different codings being used. Protocol elements
> that define how messages should be delimited/routed/etc must be strictly
> defined and easy to enforce in implementations and applications.

We never really said before.  I'm happy to extend the 0x7f to 0x7f-0xff if that is what others want.  It's not quite the same as limiting the grammar to what is permitted for field names, but it might be OK.

field-name is "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." / "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA

That amounts to a whole bunch of characters less than %x21-7E (minus ':').  A simpler check for c >= 0x21 && c <= 0x7e && c != ':' seems reasonable to me.  Then we don't have to worry about Unicode field names.  That's not a whole lot different than c >= 0x21 && c != 0x7e && c != ':' as the current PR has.

I had the distinct impression that we DID see Unicode field names in some cases though.

We wanted to avoid backward incompatibility issues that might result from tighter constraints on field *values*, which is why we never said anything before, but names might be easier.

Received on Friday, 21 May 2021 01:20:07 UTC