BUG/MAJOR: buffers: make the buffer_slow_realign() function respect output data The function buffer_slow_realign() was initially designed for requests only and did not consider pending outgoing data. This causes a problem when called on responses where data remain in the buffer, which may happen with pipelined requests when the client is slow to read data. The user-visible effect is that if less than <maxrewrite> bytes are present in the buffer from a previous response and these bytes cross the <maxrewrite> boundary close to the end of the buffer, then a new response will cause a realign and will destroy these pending data and move the pointer to what's believed to contain pending output data. Thus the client receives the crap that lies in the buffer instead of the original output bytes. This new implementation now properly realigns everything including the outgoing data which are moved to the end of the buffer while the input data are moved to the beginning. This implementation still uses a buffer-to-buffer copy which is not optimal in terms of performance and which should be replaced by a buffer switch later. Prior to this patch, the following script would return different hashes on each round when run from a 100 Mbps-connected machine : i=0 while usleep 100000; do echo round $((i++)) set -- $(nc6 0 8001 < 1kreq5k.txt | grep -v '^[0-9A-Z]' | md5sum) if [ "$1" != "3861afbb6566cd48740ce01edc426020" ]; then echo $1;break;fi done The file contains 1000 times this request with "Connection: close" on the last one : GET /?s=5k&R=1 HTTP/1.1 The config is very simple : global tune.bufsize 16384 tune.maxrewrite 8192 defaults mode http timeout client 10s timeout server 5s timeout connect 3s listen px bind :8001 option http-server-close server s1 127.0.0.1:8000 And httpterm-1.7.2 is used as the server on port 8000. After the fix, 1 million requests were sent and all returned the same contents. Many thanks to Charlie Smurthwaite of atechmedia.com for his precious help on this issue, which would not have been diagnosed without his very detailed traces and numerous tests. The patch must be backported to 1.5 which is where the bug was introduced. (cherry picked from commit 27187ab56a2f1104818c2f21c5139c1edd8b838f)