Good morning, In the current version (1.7.5), haproxy documentation states that compression is disabled if the response is not chunked and does not include a Content-length.
Unfortunately, it seems a bit limitating because some Java application servers (Jetty for sure, and some netty-based frameworks) never use chunked mode together with Connection: close. For example, when requesting a payload with Connection: close set on the client side, you'll typically receive the following response header. Date: Tue, 09 May 2017 06:07:17 GMT Content-Type: application/json Connection: close Server: Jetty(9.3.12.v20160915) Content-length is included only in the particular case where the response body fits in the server buffer, which is often not the case for large, dynamically generated content, and this is causing haproxy to disable compression. According to discussions on the jetty github, when Connection: close is present in the response, it's acceptable to simply let the client know that the response is complete by closing the connection on the server side. On haproxy side, I have noticed that you can set option http-pretend-keep alive to work this issue around, as this will remove "connection: close" from the request header, thus allowing jetty to use chunked transfer encoding. But given that Jetty is not alone in this case, I am wondering whether it would be technically possible for haproxy to enable compression in the following scenario (According to the response headers) : 1) HTTP 1.1 is used 2) "Transfer-Encoding" is NOT chunked 3) "Content-Length" is NOT specified 4) "Connection : close" IS specified (expecting EOF framed response) Kind regards
