Re: Large Frame Proposal

On Mon, Jul 7, 2014 at 3:23 PM, Greg Wilkins <gregw@intalio.com> wrote:

>
> 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.
>
>
Not all use-cases have potentially malicious users, and jumbo frames do not
solve the blocking problem.
Making frames after the first one non-state-modifying or
non-state-referencing, however, would solve that problem.



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

And what if you're forwarding to another multiplexing proxy, and only then
to a server?
Which limit applies to which request?
It gets complicated and unuseful, and one needs to be able to reject
larger-than-wanted headers anyway.

-=R


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