Re: Large Frame Proposal

On 8 July 2014 08:43, Roberto Peon <grmocg@gmail.com> wrote:

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

Not claiming it does.  Just saying that streaming is not generally
supported and thus is not a string argument against the proposal.


> Making frames after the first one non-state-modifying or
> non-state-referencing, however, would solve that problem.
>

To this I make the response that has been made to jumbo frames - there
appears to be lots of discussion about how/if this is possible and it is
unclear if there is a single proposal.  A pull request would be helpful to
consider if this is a real proposal.


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.
>
>
This is a straw man argument as it pretends that these limits/problems
don't already exist in http/1 and the current draft.   There are limits all
along the path and headers can and do get rejected because of size.

All we are proposing is that a hop declares what it is prepared to accept.
This makes no representation what size up-stream or down-stream entities
will accept and is not an end to end guarantee.

Not having the setting and just a 14 bit length does not guarantee that a
proxy will accept the header and it can still send a 431.

The limit on frame size is not to give an end to end guarantee.   It is
there to configure multiplexing efficiency for the next hop. That's all, no
more no less. And that is a very valuable thing to do.

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.