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

On 03.06.2014 11:01, Roberto Peon wrote:
> If one does so, then different frames have different max sizes, and 
> are parsed differently.
You seem to assume that the length field needs to have a different 
length, although I think this isn't really necessary.
> 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.
The examination of the frametype is necessary today to detect if it is 
header / continuation frame and to handle it differently.

> This is more painful, more codepaths and slower in the common 
> case/common path.
Even better would be if header frames could be handled like other frames 
and forwarded without much modification.

>
> -=R
>
>
> On Tue, Jun 3, 2014 at 1:48 AM, Roland Zink <roland@zinks.de 
> <mailto: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
>         <mailto: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).
>
>
>
>