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

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

Received on Tuesday, 3 June 2014 08:48:56 UTC