W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2015

Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Mon, 12 Jan 2015 20:06:52 +1300
Message-ID: <54B3728C.2050004@treenet.co.nz>
To: Julian Reschke <julian.reschke@greenbytes.de>, ietf-http-wg@w3.org
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/01/2015 7:41 p.m., Julian Reschke wrote:
> On 2015-01-12 06:24, Amos Jeffries wrote:
>> ...
>>>> If you can't think of a concrete action to take based on
>>>> this setting, I would ignore it.
>>> 
>>> Do we have any implementations that actually do something with 
>>> this setting?
>> 
>> Squid is. The combination of CONTINUATION frame and dense HPACK 
>> compression allows senders to allocate a headers block up past
>> the GB *per message* size ranges. Hardware that comes with TB of
>> RAM is pretty scarce still. ...
> 
> 
> OK, do you we have *client* implementations doing something with
> it.
> 
> Let's assume a UA constructs the message and it has 8K of headers,
> but the server has indicated it only takes 4K. What is the UA
> supposed to do?
> 
> a) Fail the operation immediately? b) Send the request anyway? c)
> Try to do something to reduce size?


Whatever it likes. The protocol has specified that the remote peer is
probably going to reject it if delivered. The rest is a use-case
specific implementation detail.

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUs3KMAAoJELJo5wb/XPRjV1gIALOmu1atLLg5TmKScwq4kE+6
U61T5JIaN3TDIMu3qpqBGXvrXTUCAhDg9EygJbD+0kpbuwgzUB+ZrTVuhGlnCek8
elamhK8TP+8TAbHpIgImbd6YilprEPuQSN5C0pTC38B0MA/FsgST3vAev5nzEtz9
DEohCy2LBIiWJVa0pDrzIT6waR2Uf1vV/lHjY/LBjk1F4apw90xhLVhi+tNMyJfs
pYMMdDMsbfmC3gg7x/6dMJLY0lmp9Tbe3t+JaCOejtbMylCd/bgDdgRwCG6T2Ppd
ontbaouIjX1a0PLmdzd1tILWa5qywjeApjPfm84NXznMjLIxAKJ7Yk5LPjMLK4k=
=6nJ+
-----END PGP SIGNATURE-----
Received on Monday, 12 January 2015 07:07:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:42 UTC