Re: #541: CONTINUATION

Thanks for clarifying this, Jason. I misunderstood earlier. Option 4
seems to really be more about guardrails.  IOTW expose a setting that
will inform the peer about header blocks > X vs just send a go away
and have them guess why.

>From a client POV, and where the client only sends 1 header frame,
this seems to simplify processing. Since the max the client can
receive is one header frame, it only needs to deal with the error case
when the server couldn't fit its response into that.

If on the other hand the client deviates from default, or pays
attention to dynamic settings from the peer, we have more moving
state, and more work than status quo. This is opt-in complexity,
though.

I'm still ok with option 4.

If I've again misunderstood something, do call me out!
-A

On Fri, Jul 4, 2014 at 11:09 AM, Jason Greene <jason.greene@redhat.com> wrote:
> 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 Sunday, 6 July 2014 17:16:41 UTC