If you're concerned that headers are being sent a byte-at-a-time (slowloris style), then you could do that with a regular headers frame anyway. If you're concerned that the overhead of frames is blowing up the bandwidth, then that could happen with PING, SETTINGS, DATA, etc. and is not unique to HEADERS or HEADERS processing. It is also point-to-point, and so any non-malicious client should be unaffected by malicious clients. The requirement to send END_HEADERS unless it is at max size adds a DoS vector because it makes it impossible for a proxy to forward anything or send anything until it has buffered the entire HEADERS, even when it has all of the information necessary to figure out to which server it should forward. It is better to allow a proxy to forward data if it can. -=R On Sat, Jun 28, 2014 at 1:23 AM, Greg Wilkins <gregw@intalio.com> wrote: > > On 27 June 2014 22:16, Willy Tarreau <w@1wt.eu> wrote: > >> Would that be OK for every one ? > > > It would help with my concern of Continuations being used as a DOS vector > with 1 byte per frame, so long as you are proposing text that say a send > MUST NOT have the END_HEADERS bit clear unless the frame is at max size? > Any receiving can treat non full frames without the END_HEADERS bit set as > a protocol error? > > Note that it does not address my concern of code that is not used by > 99.99% of users but that complicates the handling of every frame and will > only get used/tested in a tiny minority of deployments. Such code is > asking to contain lurking bugs and exploits.... however I think my > fundamental concern with continuations probably goes back to their jumbo > frame nature and hpack's single state table... so we would need a big > rewrite to address that. > > 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. >
Received on Saturday, 28 June 2014 19:48:30 UTC