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: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 12 Jan 2015 08:13:57 +0100
Message-ID: <54B37435.3030505@gmx.de>
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

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