Re: Large Frame Proposal

>
> 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 possible in the general case for a proxy with no application
knowledge of what it's proxying and/or reason to distrust it's peers.
That's not the same as saying that streaming HPACK isn't possible anywhere,
ever.


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


I believe this isn't true, but am restricting that conversation to the
#541: CONTINUATION thread. *tl;dr*: You're gonna have to do it anyway.


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