We observed this error a lot for a recent test:

** Reason for termination = 
** {data_error,[{zlib,inflateEnd_nif,[#Ref<0.412400069.282722305.201902>],[]},
                {zlib,gunzip,1,[]},
                {ts_http,decode_buffer,2,
                         [{file,"src/tsung/ts_http.erl"},{line,72}]},
                {ts_client,handle_data_msg,2,
                           [{file,"src/tsung/ts_client.erl"},{line,1127}]},
                {ts_client,handle_info2,3,
                           [{file,"src/tsung/ts_client.erl"},{line,229}]},
                {gen_fsm,handle_msg,8,[{file,"gen_fsm.erl"},{line,483}]},
                {proc_lib,init_p_do_apply,3,
                          [{file,"proc_lib.erl"},{line,247}]}]}

The request was made with Accept-Encoding: gzip and the server answered with an gzip encoded response. BUT the server did send the response without Transfer-Encoding: chunked. The previous implementation of ts_http:split_body/1 did append a newline to the body.

This PR changes two things:

1. simplified & fixed the regular expression used to perform the split: The body match needs to be greedy in order to collect trailing newlines if present
2. do no longer append \n to the extracted body. The response body does not need to be terminated by \r\n (unless the response is chunked, which is never the case when ts_http:split_body/1 is used)

We first wondered, why this hasn't been a big problem in our many thousand test executions because zlib:gunzip/1 will always fail if you append <<10>>. The reason why this did not happen all the time is, that it is very uncommon to have a not-chunked but gzipped response. In case the response is chunked ts_http:decode_chunk/1 is used to perform the split of headers and body which does not suffer from the same problem.