Re: Large Frame Proposal

On 8 July 2014 04:23, Johnny Graettinger <jgraettinger@chromium.org> wrote:

> Hi Greg et al,
>
> Thanks for the proposal! Some non-anticipated feedback:
>
> This is orthogonal to CONTINUATION (and could also be addressed by
> pre-pending the encoding length within the HPACK encoding, as has been
> suggested). The problem with doing so is that it precludes the possibility
> of streaming HPACK.
>

Streaming HPACK is already not possible as it creates DoS vectors.
Either we fix that problem - ie make header blocks able to be fragmented
and interleaved,  or we have to face up to the fact that we already have
jumbo header frames.



It's not a requirement that an endpoint close the connection after deciding
> that headers on a particular stream are too large. It does require that the
> endpoint be willing to incrementally process header block fragments as they
> arrive, to avoid unbounded buffering. With that, it's fully possible for an
> endpoint to tightly bound it's memory commitment in the face of large
> headers on a stream, without tearing down the connection.
>

Indeed - but a lot of work for nothing. Best just to tell the peer not to
send them in the first place.


>
> Yes, this is a concern, but is easily solved (and is why Chromium is
> emitting smaller continuation frames to ensure good interop coverage within
> h2-13).
>

Which is precisely the reason I have moved from the
I-can-live-with-CONTINUATIONS-because-I-can-ignore them camp, back to the
I-can-not-live-with-CONTINUATIONS camp.      Several proposals have been
made to make them ignorable for small headers, but as they have not been
accepted then it looks like we all must support continuations and
implementations that do not will be hunted down and excluded from
interoperability, even if they never ever need large headers.

Mark - can you open an issue for this one-   CONTINUATIONS looks like it is
only needed for large headers, but it is actually a non optional part of
the specification.

cheers



-- 
Greg Wilkins <gregw@intalio.com>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.