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

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 Monday, 2 June 2014 23:03:13 UTC