W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2021

Re: Permitted characters in HTTP/2 fields

From: Greg Wilkins <gregw@webtide.com>
Date: Tue, 25 May 2021 09:31:33 +1000
Message-ID: <CAAPGdfGf-AiE=jUDd_9o_xpe-Jc8iJvPU-xtqc-4gr3U+-WtHA@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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
Received on Monday, 24 May 2021 23:31:58 UTC

This archive was generated by hypermail 2.4.0 : Monday, 24 May 2021 23:32:01 UTC