When one is doing 1:1 proxying there is no real downside to allowing transmission before the entire suite of headers has been received. This is especially true if used for non-browser usecases. When remuxing among multiple clients/servers, life is harder, and there are a number of different tradeoffs. -=R On Sat, Jun 28, 2014 at 1:38 PM, Jason Greene <jason.greene@redhat.com> wrote: > > On Jun 28, 2014, at 2:48 PM, Roberto Peon <grmocg@gmail.com> wrote: > > > 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. > > True, although if it does that the HOL blocking will force it to buffer > all the other streams, so its not reliably helpful to break things up like > that. > > > > > > -=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. > > > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > >
Received on Saturday, 28 June 2014 20:48:26 UTC