We need to protect this validation by a configuration flag to make sure users can disable it.

Taking into account the RFC requirements to always run this validation (at least by default), the fact that validateValues == false by default, I would propose to use validate flag that controls header name validation. While in practice the check validates a value, I would say that technically it's a "validation of a preudo-header name". The purpose of validateValues is quite different. It's disabled by default because it will cause significant perf overhead for most users.

Please check the new commit.

Taking into account the RFC requirements to always run this validation (at least by default), the fact that validateValues == false by default, I would propose to use validate flag that controls header name validation.

@idelpivnitskiy Is this "always" requirement any different from checking that byte ranges for values are valid, which we skip by default?

The biggest differences are:

1. the cost associated with a check
2. how likely is it to hit the problem (messing up with pseudo-headers seems more likely)
3. how it will affect the h2-protocol related flow vs user's business logic (having a bad char in some header won't impact h2 codec or h2->h1 transition)
4. is the header name required to perform the check

This case seems to me close to TE header validation we have in HpackDecoder.