Hi, We use HAProxy in front of Apache CouchDB. CouchDB has an endpoint with some interesting characteristics called _changes. With certain parameters, that are commonly used, the response is effectively endless, streaming the updates to a database as they happen using chunked transfer mode. In periods where no changes occur a 'heartbeat' is periodically sent to keep the connection alive. This heartbeat is small, consisting of a single newline character. Each heartbeat is sent as a complete chunk.
We found that HAProxy 2.6, if slz is compressing the response, will only pass on these chunks to the client when three have arrived from the backend. The delay in receiving these chunks at the client causes them to timeout. If we USE_ZLIB=1 instead, the problem does not occur and the heartbeat chunks are sent in a timely manner. We recently upgraded from 2.0.31 to 2.6.13 which introduced this unexpected change. We eventually tracked this down to a change in libslz. With 2.0.31 we were building libslz 1.0.0. With 2.6.13 we used the in-tree version. We bisected haproxy from 2.0 to 2.6 and found that the switch to in-tree slz was the trigger point between good and bad behaviour. We then further bisected libslz between v1.0.0 and b06c172 (the point at which it was merged in-tree). This pointed at http://git.1wt.eu/web?p=libslz.git;a=commit;h=b334e7ad57727cdb0738b135bb98b65763d758b5 as the exact moment the delay was introduced. In summary, we think HAProxy should not indefinitely buffer a complete chunk of a chunked transfer encoding just because it is below the level deemed worthy of compression and should instead send it to the client in a timely manner. This affects clients using http/1.1 or http/2. Noting that Apache CouchDB only supports http/1.1. We can work around this by disabling compression for this endpoint, though this is not our preference. Regards, Robert Newson Apache CouchDB PMC
