- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Mon, 07 Jul 2014 20:02:35 +0000
- To: Johnny Graettinger <jgraettinger@chromium.org>
- cc: Greg Wilkins <gregw@intalio.com>, HTTP Working Group <ietf-http-wg@w3.org>
In message <CAEn92To91LMwMzRubur5mWLfAc=f+XZhS0uLFSdQh-Z-7ceo6A@mail.gmail.com> , 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 else. 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 ? Poul-Henning 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