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

On 2015-01-12 08:06, Amos Jeffries wrote:
> 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