- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 12 Jan 2015 08:13:57 +0100
- To: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On 2015-01-12 08:06, Amos Jeffries wrote: > -----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. I see lots of opportunities for interop problems here, unless we either remove this or make it stricter, for instance when popular servers/services reporting a maximum header size that is below of what they actually accept in practice, thus there'll be an incentive to ignore it to avoid unnecessary client-visible errors. Can the *UA* implementers please provide feedback on what they are doing with this information? Best regards, Julian
Received on Monday, 12 January 2015 07:14:38 UTC