- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Tue, 08 Jul 2014 15:41:48 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- cc: Mark Nottingham <mnot@mnot.net>, Roberto Peon <grmocg@gmail.com>, Jason Greene <jason.greene@redhat.com>, Johnny Graettinger <jgraettinger@chromium.org>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
In message <CABkgnnVevm3ar2EG_S8iQ-7sXEPcsTFYAao=GP=D83zS=NEttw@mail.gmail.com>, Martin Thomson w rites: >On 7 July 2014 21:07, Mark Nottingham <mnot@mnot.net> wrote: >>> 1) declaring a limit on the compressed header size >[...] >>> #1: Sure, though I suspect its utility will be minimal when proxies/gateways are in the mix. >> This would partially mitigate #550, and substantially help #551. > >The conclusion I'd drawn there being that a limit on encoded header >block size doesn't really do anything to limit the state commitment >required to process a request or response. There is definitely some >utility in having a limit, but it's marginal. The limit is not on what amount of state will be needed later on, but on how much state will be needed to get to the point where the receiver can judge the (non-)hostility of the request and estimate how much state will be needed later on. >The setting really only becomes useful - and arguably necessary - when >you consider the expanded frame size. It would be useful also for the unlimited in time&space CONTINIUATION scheme in draft -13, but would need to specify not only the aggregate size, but also the count of frames and the maxium duration of their reception. -- 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, 8 July 2014 15:42:12 UTC