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

> On Jan 12, 2015, at 1:13 AM, Julian Reschke <> wrote:
> 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,

With or without the setting, a server or intermediary is not guaranteed to send a 431. A constrained server/intermediary is unlikely to want to spend CPU/memory to process excessive header blocks, and since the compression context is invalid without doing so, GOAWAY/hangup is likely. So I fail to see how this creates any *new* interop problems. It only provides extra information that can be used to avoid poor behavior.

Itís particularly useful to intermediaries that are coalescing multiple client connections to a single origin server. Without this information, one bad actor can effectively lead to the termination of a connection in use by many good actors. With the information, the intermediary can ensure it never forwards such requests, leaving the failure to the bad actor.

> 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.

The possibility of losing your connection is a pretty strong incentive IMO.

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Monday, 12 January 2015 15:39:59 UTC