Yuras
commented
8 years ago This issue also confuses http-client. It doesn't read response body in case of 204 status, but tries to reuse the connection. At a result, the next request fails because it reads the terminating chunk from the previous response instead of status line for the current response. The fix proposed by @wrl314 works for me (thanks!) What about merging it to 0.9-stable and making a release?
gregorycollins
In snap-core 0.9.8.0 a commit was made (10f44610f5e597f665de7c3e8d07a70870c97688) in response to issue #242 which removes Content-Length header for both 204 and 304 responses. This is correct for 204 responses per RFC 7230.
But with snap-server 0.9.5.1 (latest on hackage), sendResponse adds "Transfer-Encoding: chunked" header when Content-Length is missing, response is HTTP/1.1 and not a HEAD method.
The result is that a 204 response has a "Transfer-Encoding: chunked" header which violates section 3.3.1 of RFC 7230 : "A server MUST NOT send a Transfer-Encoding header field in any response with a status code of 1xx (Informational) or 204 (No Content)."
When snap-core 0.9.8.0 with snap-server 0.9.5.1 is behind haproxy 1.5.14, such a response confuses haproxy causing it to hang until timeout. While haproxy may be at fault for not recognizing the terminating chunk and closing the connection with the client, it is probably not expecting chunked encoding at all on 204. It seems snap should adhere to RFC here to ease compatibility.
It looks like HEAD of snap-server may not have this problem as sendResponse there does not add Content-Encoding for 204 or 304 responses. Can that change get back ported to 0.9.x?