Hi,
two days ago I released haproxy 1.4.3 and 1.3.24.
First, very few issues were reported on 1.4.2. It seems we managed
to quickly squash most of the bugs, which is a good news for everyone,
especially those in more sensible environments who need to wait for
the beast to look nice before even thinking about ugprading.
Version 1.4.3 fixes some remaining issues after 1.4.2. One of them was
introduced in 1.4.2 when trying to fix the connection establishments
with closed client-side connection. It caused some connection requests
to be sent to server on some incomplete HTTP requests (accept immediately
followed by a read error). That also happened if some tcp-request rules
performed a reject after a delay. The connection was in fact established
then immediately closed. Still it was not acceptable. An unfortunate side
effect of this issue was reported by Isidore Li (who provided me with a
lot of useful info to reproduce the issue) : layer7 based hashing could
be called with a NULL URI and cause occasional segfaults if such a
request was encountered. So both issues were independantly fixed.
Another thing that I found was that it's very common to see configs
where http-only options are enabled in tcp-only sections (eg: option
httpclose), where people get into trouble trying to understand why
their config does not work as expected. Thus, a new control was added
for all http-only options. Now a warning is emitted if they are found
in tcp-only sections. This is also true if those options are inherited
from default sections. Some will probably complain that now they get
some warnings, but they must keep in mind that a warning indicates
that something was not working as they were expecting it to. So it
will be a good opportunity to fix wrong configs.
A new minor feature was also added on user request. Since we now
have "force-persist" to be able to force access for an admin to
a server being installed, someone explained to me that it would
be nice to be able to set a server in the "disabled" state in the
config. This made a lot of sense and makes it possible to pre-configure
a server farm several days in advance without risking any accidental
public access. So I have added this new "disabled" keyword on the
"server" lines.
That's about all for 1.4.3.
On the long stable 1.3 side, the relevant fixes since 1.3.23 have
made their way to a new release. Most of them are relevant backports
of fixes discovered in 1.4. Some of them maybe of interest to a few
users :
- fixed support for HTTP/101 responses (used by WebSocket)
- unresolvable hostnames were reported as errors but did not
cause the startup to fail
- "balance url_param" could select a down server in very rare
circumstances (only one server remaining with a weight that
is lower than all others and does not divide them).
- hostname is now correctly null-terminated (issue encountered
on FreeBSD with very long hostnames)
- SIGPIPE is now caught even if MSG_NOSIGNAL is defined. This
fixes the recently reported issue on FreeBSD 8 where haproxy
is killed by a SIGPIPE upon network errors.
- the "disabled" server keyword was backported (more simply
though) as it is useful in 1.3 too.
There will probably be an 1.4.4 soon with the option to pretend
we want to keep a session alive with the server and close it
afterwards. But that's not a valid reason for not fixing your
1.4.2 :-)
Now you know where it is :
site index : http://haproxy.1wt.eu/
sources : http://haproxy.1wt.eu/download/1.4/src/
changelog : http://haproxy.1wt.eu/download/1.4/src/CHANGELOG
binaries : http://haproxy.1wt.eu/download/1.4/bin/
and for 1.3.24 :
sources : http://haproxy.1wt.eu/download/1.3/src/
changelog : http://haproxy.1wt.eu/download/1.3/src/CHANGELOG
binaries : http://haproxy.1wt.eu/download/1.3/bin/
Now that things are calming down, we'll soon be able to start working
on 1.5.
Have fun,
Willy
