Re: Permitted characters in HTTP/2 fields

Actually, my comments are a little out of date and the current text is
pretty much in line with what I'm advocating, especially with the last
commit.    A bit more supporting text in the PR would still be good for
recording why.

On Tue, 25 May 2021 at 08:25, Greg Wilkins <gregw@webtide.com> wrote:

> Cory et al,
> In totally ok with the principle of be strict in what you generated and
> relaxed in what you accept.
>
> I understand the effort here is to try to tighten up that relaxed
> acceptance a bit to ensure that security issues are not created as a
> result, but not to impose strict requirement for full Field ABNF compliance.
>
> I just find the text is too imprecise and the motivations for it are not
> sufficiently well capture either in the text itself or the PR. It may be
> clear to those that attended the meeting, but I find there is missing
> context.
>
> If we want to allow flexibility but avoid security issue than we need text
> that says: implementations SHOULD (or MAY) enforce the full ABNF ; in order
> to avoid security issues [insert ref] all implementation MUST NOT send or
> accept fields with <insert precise definition here>.
>
> There is now some discussion on exactly what characters should be
> allowed/rejected. Clearly starting exactly the security issues that are
> being avoided should assist with well defining that set.
>


-- 
Greg Wilkins <gregw@webtide.com> CTO http://webtide.com