Re: Large Frame Proposal

In message <>
, Johnny Graettinger writes:

>The problem with doing so is that it precludes the possibility
>of streaming HPACK.

While it may be an advantage (how big ?) for a client to be able to
"stream HPACK" it is a major inconvenience to everybody else in the
HTTP network topology to have no idea how much data is incoming.

Given that the CPU/MEM performance bottleneck is everywhere but the
client there needs to be really good arguments for shifting the
inconvenience of finding the total length from client to everybody

Where are these arguments ?  I cannot find them.

It seems like "streaming HPACK" is an merely a neat idea and I have
certainly not seen any examples of clients that cannot function
without it ?


PS: In a previous email I outlined several strategies tiny clients could
use, I won't repeat them here.

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 Monday, 7 July 2014 20:02:58 UTC