W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: #541: CONTINUATION

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>
Message-ID: <81719.1404834108@critter.freebsd.dk>
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

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:09 UTC