Hi, On Tue, May 08, 2012 at 06:57:04PM +0200, Baptiste wrote: > "Never" unless SPDY become the new standard for HTTP/2.0, validated by IETF. > > To be honest, I talk from time to time to Willy about SPDY protocol. > And he does not want to implement a protocol which is not a standard > within HAProxy. > He prefers waiting for the standardized HTTP/2.0 and because some > stuff in SPDY are not > > F5 is not the only one, boostedge from Activenetworks, nginx, apache > (through a module), and others have implemented or are implemting > SPDY. > > But Willy is the best person to answer you, I hope he'll answer you soon :) > > Note that I'm on your side: I'd be keen to have SPDY implemented in > HAProxy. Unfortunately, it's a long time job and HAProxy is missing > some major features before implementing SPDY (well that's my point of > view).
The point is that SPDY is nice and brings a lot of performance boost, but at the expense of a much more complex infrastructure and a more fragile handling of DoS attacks. It's around 100 times easier to DoS a SPDY server than it is for an HTTP server because you can force the server to parse and process large requests with very few bytes due to the header compression. The header compression also means that double buffering becomes mandatory, which comes with a cost for intermediaries. At the moment, SPDY ensures that HTTP/1.1 can be optimized as much as possible, but there are inherent issues in HTTP/1.1 that have to be addressed in HTTP/2.0 (CRLF, long header names, folding, etc...). That's why with the guys from Squid, Varnish and Wingate we presented an concurrent proposal to the IETF one month ago : http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00 Right now there are 4 drafts for HTTP/2.0 : SPDY, ours (which is really just a small draft and which we still need to work on), the MS guy's and hopefully Waka if Roy Fielding finds time to write it and publish it. All of these drafts use very different concepts, and with a component such as haproxy, it can be between 3 and 6 months of work before such a support is implemented, and maybe more for the most complex ones. For this reason, I don't want to implement something which is going to move soon. It's very likely that most of SPDY will be adopted as HTTP/2, but better work on HTTP/2 when it takes shape than work on SPDY right now and throw everything away once it's just finished. Hoping this clarifies the situation, Willy
