- From: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Date: Sun, 13 Jul 2014 18:14:50 +0000
- To: Johnny Graettinger <jgraettinger@chromium.org>
- cc: Amos Jeffries <squid3@treenet.co.nz>, HTTP Working Group <ietf-http-wg@w3.org>
In message <CAEn92TrULC1rniqaG-vFYw9K77d2g97=ANywW3x5UyPfPSR=jA@mail.gmail.com>, Johnny Graetting er writes: >--20cf3079bc781d287e04fe16336c >Content-Type: text/plain; charset=UTF-8 > >On Fri, Jul 11, 2014 at 7:53 AM, Amos Jeffries <squid3@treenet.co.nz> wrote: > >> Given the size of a large frame up-front a proxy can actually stream the >> start of that frame before the end has arrived if you trust the sender >> will complete it cleanly. >> > >The proxy cannot know the encoded size of the block until it's run that >complete block through it's send-side HPACK context. That context is >different than the recv-side context, and it will almost certainly result >in a different block length. actually, if there exists such a intimate relationship between the backend and the proxy, the backend can compress the headers to make that possibl. -- 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 Sunday, 13 July 2014 18:15:21 UTC