Beyond just the DoS impact, I think it's simply required from a correctness perspective. Unlike our other limits in SETTINGS, this proposed one must not be exceeded, since it's incorrect not to process control frames that modify session state, like the compression context. On Tue, May 7, 2013 at 5:41 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>wrote: > In message > <abb2201dec3a405aa735f1d09a7a8404@BY2PR03MB025.namprd03.prod.outlook > .com>, Mike Bishop writes: > > > Better to know up front. We can specify an initial (large) value > > and peers only need to change it if they need to restrict to a > > smaller value. > > I think you got that backwards... > > The default limit needs to be small, until the server is willing to > invest resources in the client. > > (Repeat after me: HTTP/2.0 SHALL make DoS attacks harder, not easier.) > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > >
Received on Tuesday, 7 May 2013 20:56:59 UTC