Hello Willy, Thank you very much for the detailed answer. Some people on the jetty list are arguing that neither chunking or EOF framing gives a complete guarantee that no failure occurred on the server side at application level (ie: exception thrown while streaming the response). https://github.com/eclipse/jetty.project/issues/805
Even so, I would not consider it a good reason to ignore the additional benefits of chunked transfers, better error detection capability on the network stack just to name one. Short story, they are (unfortunately) quite happy with the current behavior despite the remarks. Out of curiosity, I ran some tests on Tomcat 7 and it had no problem using chunked transfer along with connection: close, I'll keep that in mind for my next project. Back to haproxy, I understand the reasons why it feels wrong to compress a stream that might be incomplete and make it appear as a valid message for the client. But correct me if I am wrong, if the client was talking to the server directly without haproxy in the middle, wouldn't it be exactly the same? I mean, he could have its connection closed due to an error and assume that the response is complete without any way to tell the difference. My question is, are you really generating a situation that would not otherwise happen? Also, in my particular use case, I am running a XML/JSON webservice, the client side would notice that the message is incomplete while decoding it so it would not hurt that much. The config lets you decide which content-type you want to consider for compression so it could be possible for the operator to decide what's safe and what's not. Anyway, I am going to start testing "http-pretend-keepalive" in production because I admit it seems to be solving my compression issues, I may run a comparative load test to see if there is any serious overhead but I don't expect so. Thanks again Kind regards
