Re: Fragmentation for headers: why jumbo != continuation.

On 11 July 2014 10:41, Roberto Peon <grmocg@gmail.com> wrote:

> Flow control of headers ends up being problematic even when there is no
> compressor, since, on the flip side of this coin, you can't always predict
> which headers are necessary for interpretation of a request, and thus you
> end up with smart attackers sending all but that last thing for every
> stream and affecting a much more effective slowloris attack.


This is true.  But if we can break the dependencies between the order that
we decompress headers, then I think both proposals are pretty much the same.

With fragmented but not flow controlled headers, and proxy or endpoint is
still going to have to wait/buffer until the fragment holding the necessary
information arrives.

I think we should not tie ourselves too much in knots over what bad actors
can do... so long as a bad actor can only screw with their own stream and
can't take more resources from an impl that it is prepared to commit.

however, I don't think the will is there to start again from framing layer,
so happy to ignore my suggestion for the purposes of this thread.

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.