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

Re: Fragmentation for headers: why jumbo != continuation.

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

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