Hi,
OK now things have stabilized a lot, not yet in terms of code, but
at least in terms of usability. There were no bug affecting the
state machine nor data integrity since last release, which hopefully
means that we're now safe again.
This one is called 1.4-rc1, which indicates that we should be slowing
down and spending more time on regression testing than on core
development so that persons testing the RC series can get a
somewhat reliable idea about what the final one will look like.
That also means that we should try hard not to change existing
config syntax or semantics as of now. I'd still like to add the
"return" clause that several people have asked for, since it
should be somewhat easy to do a basic implementation for now
(only return raw files). Also, the end-to-end keep-alive is
not there (by lack of time), but maybe I'll add it as an
experimental feature before -final if it does not require to
change existing code.
In RC1, a lot of things have been added recently :
- the server maintenance mode from Cyril Bonté, which was still
discussed a few threads before this one ; It is entered/left
by issuing "disable server" or "enable server" on the stats socket
in admin mode.
- http authentication (server and proxy) with plain-text as well
as ciphered passwords. This can be used in ACLs, stats as well
as new http-request allow/deny/auth rules. It supports userlists
(think customers), groups and users. After a few tests, it looks
very powerful and I have already put it in front of my proxy :-)
This task was sponsored by Artegence(*) and performed by Krzysztof
Oledzki. Check the docs for examples on how to use it. For more
info on Artegence, they're here : http://www.artegence.com/
- conditional request/response header rewriting. Many people have
asked for if/unless conditions after req*/rsp*, this was now
done. For instance it allows one to replace a header if the request
matches a certain URI, or to add a specific header depending on the
request's source. Please note that it's the first implementation
making use of response ACLs and while they appear to work as
expected, there might be surprises left.
- anonymous ACLs declared inline. It's sometimes painful to have to
declare an ACL for one single entry. For instance :
acl from_upload_server src 192.168.1.1
acl is_img path_beg /img
use_backend bk_img if is_img || from_upload_server
Now using braces, you can create an anonymous ACL where one is
expected :
use_backend bk_img if { path_beg /img } || { src 192.168.1.1 }
It is not recommended to use that form unless it appears even less
readable/maintainable to have to declare and name the corresponding
ACLs.
- haproxy can now indicate to a server it is being checking in what
state it sees it (up/down/maint, weight vs backend's weight, total
conns, ...). This can help where the persons operating the servers
don't have access to haproxy and have to update/reinstall servers
during production hours. Using those features, they can program a
down state and check in the logs when their change has been considered.
This is a good complement to disable-on-404.
- HTTP/1.1 responses with status "101 switching protocol" are now
handled properly by establishing a tunnel between the client and
the server after the end of both messages. This makes haproxy
compatible with some protocols such as WebSocket which make
extensive use of the GET + 101 + Upgrade mechanism.
Now for the timeframe, I think that several of us still have minor
things to merge, so what I'm proposing is that I'll still emit about
one new RC per week, and that we declare the final one once we have
spent about 7-10 days without observing a regression or an annoying
bug.
In the mean time, doc reviews and updates are welcome :-)
1.4-rc1 is currently available here :
http://haproxy.1wt.eu/download/1.4/src/
Regards,
Willy
