-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
