Hi Jinn, a big "thumbs up!" for that followup. I really couldn't answer in a better way.
My initial mail was just a kind of: "I would like it! (but that doesn't mean anything)" I do understand all arguments provided by Willy. Best regards Andreas Mock -----Ursprüngliche Nachricht----- Von: Jinn Ko [mailto:hapr...@mx.ixido.net] Gesendet: Dienstag, 24. September 2013 16:23 An: haproxy@formilux.org Betreff: Re: AW: GA Release of 1.5 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, It's good to get a better idea of what's needed to see a GA release of 1.5. We've been keenly awaiting the GA release, and I certainly understand the need to ensure the high performance that we've all come to expect of HAProxy. In this case, however, I would propose the features are significant enough to stabilize what's there and manage expectations. An important reason to release the SSL feature set as is could be for the potential to release timely security fixes when vulnerabilities or exploits are discovered. With the knowledge that server-side keep-alives aren't currently supported together with SSL we could plan our production deployment to take this into account until a future release does support the combination. Documentation could very well reflect these limitations and serve to manage users expectations. On 2013-09-23 11:56, Lukas Tribus wrote: > Hi! > > >> If you feel SSL support being stable I would really like to see >> a release. This is THE main reason for 1.5. > > I understand your point, but server side keep alives for example > are important when you run SSL on the backend side, otherwise you > end up establishing a new SSL session for each and every HTTP > request. > > I doubt that would scale very well. > In our case we're deploying a single service and are using the 1.5 branch primarily to support websockets over SSL, something that was fiddly, if not difficult, prior to having SSL support within HAProxy. One of the main reasons for the difficulties with websocket over SSL is the treatment of the Connection header, which the alternative SSL terminator, nginx, is in fact observing the correct behaviour defined in the relevant RFC. Alternative means of terminating SSL are also fiddly and we haven't tested them with websockets. The good news is haproxy-1.5-dev has been working great for the past few months that we've been using it, albeit only in pre-production and performance testing environments for now. The performance aspect hasn't been a bottleneck for us so far, so is a minor concern. > >> Please don't put the burdon of patching relevant fixes to the >> current users. (It's not patching, but filtering which patches >> are relevant). > > That was just a proposal; whether its achievable or not depends on > you. > Unfortunately we don't have the resources to maintain a branch to which we could backport relevant fixes, not to mention the overhead of managing any security related fixes. > Now if you are a multi national, multi billion dollar company > implementing haproxy in a commercial product, you can probably > justify the effort (or the risk of a unstable component in your > product - in the end this is just a numbers game for a big > company). > > If you are a haproxy end-user, I don't see why using a current > snapshot of the code would hurt (*if you have the time to deploy > an OSS solution*). Sure, you shoud not blindly upgrade to more > recent code without extensively testing it first, but that may be a > good thing to do with stable releases as well. We'd certainly fall into this category, however while we're a start-up (with no funding), this isn't a great situation to be in. The concern for potential security issues is also valid. > > If you don't have the time and need those bleeding edge features > today, then you should probably stick to a commercial solution, > like those from exceliance.fr or loadbalancer.org. I'm not sure if either of these offer websocket+SSL support, but certainly worth investigating. > > I don't think releasing new stable branches every 6 months is a > good thing, because in the end, you need long term support for > this deployments. You don't want to upgrade from one stable major > release to another every 12 months because of their deprecation, > right? While the release cycles are a topic in themselves, supporting relatively major developments such as SSL and websocket support is important for the community. > Can't have all the features in stable branches right away and then > expect those branches to be supported for years to come, imho. Point taken and certainly an important consideration. Best regards, Jinn -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJSQaA5AAoJEKH/0oz1HLHUn6gP/juYmJSTcXoXP7UkFPRHQEkF hXd3juxhGmAePLQPm0XqcOy/B/6K1mc/ECf7LGOuO5nWWeG3b10x6BamJBBVBZNf 81mds3IeVh9cwDNCSUxejr+A9CBAB6QK1RQ+ula4o3HnS3j1vaPT7g6xBFr40bQF SnBdNLdMvudGlJuGFJniorrao/CPMcaBkCuz0hCGZwJWQQb7U10qUt5+djd0ZQKu p5JS6K7/1rQ9+pjiYdr1HAxk5W4HqjJPHboP/sH0NHuJtLcsdgBXCZbndP7z6w1H YHL7x620JpDZFfIcLUhZf3GZpXTsC+DGsLrxeaW3dVUEP9X/pPrtmB6x8wggGRty ZFboXcFAirhdMlZ03dQScbKdZr0pkgQ0fU/MquXk0wDKJGkAfE8ztNNtu/wxDA6N qiUIFrYAGwnP7WOhqZUaX8O978nP4sGLEtwoayNTNJk/upWTOQG5TuNIVodgAGNY MypyG44IFj6wt7fZ6EwiYSGYJKtRJ/ySlZUNt/OoLKGq/DZaaQJnORHMszfRPnjs hVC0cYw4Wqam8oCrD+aI6FWlkWTI2ZaRsPLMNLLcZ72ri/FEmOjmLsJYfUGYptzt A1JVwmMsyUWH7nFgHjOqCbNN9Q9maY6FLZY5JaNJlRCBz0MO8K3Cd4ElY9tBnxWO zNg+ZTIrvabpaUJ53XRW =Ksk4 -----END PGP SIGNATURE-----