Re: #541: CONTINUATION

Just to be clear, option 4  is:

1) Senders must not send continuations unless they have filled and sent a maximum sized header frame.

2) Senders can not send more than MAX_HEADER_BLOCK_SIZE (or alternatively MAX_HEADER_SIZE based on decoded vs encoded size)

3) MAX_HEADER_[BLOCK_]SIZE defaults to 16KB

4) A larger MAX_HEADER_[BLOCK_]SIZE value can be specified by the sender in a SETTINGS frame 

The end result is that a proxy or a server does not have to process and/or relay unlimited data when it will ultimately reject a value <= 16KB. In the .02% cases where a value greater than that is needed, a reasonable limit is negotiated thereby mitigating the impact of HOL blocking and reducing or eliminating connection drops.

To be clear, suggestions that servers simply GOAWAY and drop the connection is not presenting an adequate solution:

1) The spec explicitly requires that all CONTINUATIONS be processed even if they are discarded. The only exception is DOS prevention. If an implementation just refused to do it, they are not really complying with the spec, and potentially excluded from walled gardens.

2) This approach effectively prevents intermediaries from coalescing connections.

There was a separate fifth proposal which was to leave continuations as is, but make them an optional extension. This 5th option is effectively a partial solution to what 4 does, only addressing the issue in the <=16KB case . Although it does have the added benefit of removing lots of complexity from the base specification, and leaves open the door for better solutions to sending > 16KB headers.

Jumbo frames was specifically excluded from this discussion, but is effectively a sixth option.

I realize not everyone cares about intermediaries (or intermediary software vendors), but they are important to the HTTP ecosystem (load balancers anyone?), and the protocol should at least make a minimal effort to address problems in this area. There are 6 workable proposals, and I am sure there are more options. I would be interested in any other solutions/ideas from those that still favor the status quo.

On Jul 3, 2014, at 5:18 PM, <K.Morgan@iaea.org> <K.Morgan@iaea.org> wrote:

> On 03 July 2014 23:34, martin.thomson@gmail.com wrote:
>> On 3 July 2014 14:24, Adrian Cole <adrian.f.cole@gmail.com> wrote:
>>> Proposal 4 (remove continuation; add setting for total header frame(s)
>>> length limit) works for me. I know details are pending, but I'm
>>> on-board with the idea.
>> 
>> To be clear, I believe that proposal 4 is two things:
>> 
>> 1. A setting that describes the maximum permissible compressed size of
>> a header block (default 16K)
>> 
>> 2. A mandate to fill all frames carrying header block fragments if
>> they are followed by a CONTINUATION
>> 
>> In the normal case, this would mean that an implementation could avoid
>> even implementing CONTINUATION.
>> 
>> That is, if we get this right and say that padding can be used to fill
>> the frame, otherwise we're back in the poop.
> 
> Could somebody please write a proposal for option #4? I can't even follow what the option really is.  For example, Martin is talking about CONTINUATION still, but in the quote from Adrian, the first thing he says is "remove continuation".
> 
> This email message is intended only for the use of the named recipient. Information contained in this email message and its attachments may be privileged, confidential and protected from disclosure. If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. Also please notify the sender by replying to this message and then delete it from your system.
> 

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

Received on Friday, 4 July 2014 18:10:23 UTC