]> git.ipfire.org Git - thirdparty/haproxy.git/commit
BUG/MEDIUM: ssl: always send a full buffer after EAGAIN
authorWilly Tarreau <w@1wt.eu>
Mon, 17 Feb 2014 14:43:01 +0000 (15:43 +0100)
committerWilly Tarreau <w@1wt.eu>
Mon, 17 Feb 2014 15:02:01 +0000 (16:02 +0100)
commit518ceddebe944f80bc6eced0a2a2ce8d4f74d015
tree376a0876427b41d0987e695f24bd12f17d1456e6
parent48f1c4e3ad4f997a6b5b90a099584d7ecbbe8355
BUG/MEDIUM: ssl: always send a full buffer after EAGAIN

Igor Chan reported a very interesting bug which was triggered by the
recent dynamic size change in SSL.

The OpenSSL API refuses to send less data than any failed previous
attempt. So what's happening is that if an SSL_write() in streaming
mode sends 5kB of data and the openssl layer cannot send them all,
it returns SSL_ERROR_WANT_WRITE, which haproxy reacts to by enabling
polling on the file descriptor. In the mean time, haproxy may detect
that the buffer was almost full and will disable streaming mode. Upon
write notification, it will try to send again, but less data this
time (limited to tune.ssl_max_record). OpenSSL disagrees with this
and returns a generic error SSL_ERROR_SSL.

The solution which was found consists in adding a flag to the SSL
context to remind that we must not shrink writes after a failed
attempt. Thus, if EAGAIN is encountered, the next send() will not
be limited in order to retry the same size as before.
src/ssl_sock.c