Re: Interleaving #481 (was Re: Limiting header block size)

If one does so, then different frames have different max sizes, and are
parsed differently.
This would imply that parsing takes more steps than it does today, as it
would need to examine the frametype, then know the length of the
length-field, then parse the length field.
This is more painful, more codepaths and slower in the common case/common
path.

-=R


On Tue, Jun 3, 2014 at 1:48 AM, Roland Zink <roland@zinks.de> wrote:

> The simple abstraction that headers + continuation can be treated as a
> single unit is similar to a single frame. Wouldn't it be a cleaner
> abstraction to merge this into one frame?
>
> Regards,
> Roland
>
>
>
> On 03.06.2014 01:02, Martin Thomson wrote:
>
>> On 22 May 2014 06:13, Michael Sweet <msweet@apple.com> wrote:
>>
>>> https://github.com/http2/http2-spec/issues/481
>>>
>> Quoting:
>>
>>> Currently the HTTP2 draft requires that HEADER frames be contiguous.
>>> Since a header block can be arbitrarily large, this presents both an
>>> obvious DoS vector and a practical issue with streaming performance and
>>> preservation of the priority scheme that HTTP/2 provides.
>>>
>>> A simple solution is to allow intervening DATA frames on other,
>>> established streams. That will allow high-priority data through without
>>> major interruptions.
>>>
>> As a DoS vector, the only parties being denied service are the parties
>> engaging in the HTTP/2 connection, which is not an issue.  Those
>> parties have far better means of denying each other service than this.
>>
>> The impact on multiplexing is largely congruent with the above.  The
>> best response here is "don't do that" with respect to large header
>> blocks.  In the worst cases (those in the tail of Richard's stats),
>> this is ~64k, which will have those parties adversely affected.
>>
>> The only place this is an actual problem is where messages are merged
>> from multiple clients (or origin servers) onto a single connection by
>> an intermediary.  In those cases, the intermediary is basically
>> responsible.
>>
>> An intermediary can apply policy to prevent this from happening.  It
>> seems like many already do this, by setting a limit (8k being fairly
>> common).  Other options include putting bad actors into TIME_WAIT,
>> putting all bad actors into a separate low bitrate connection.
>>
>> The main reason I'm against this change is that it prevents the sort
>> of clean abstraction that we currently have, which states that HEADERS
>> + *CONTINUATION or PUSH_PROMISE + *CONTINUATION can be treated as a
>> single contiguous unit.  An implementation that fails to apply that
>> abstraction ends up with the state machine Greg shared with us in #484
>> (which is incomplete, BTW).
>>
>>
>
>