Messing up Transfer-Encoding and Content-Length headers

[kachayev]

Explicitly set "Transfer-Encoding: chunked" might lead to a chunked response being sent alongside with the Content-Length header.

(require '[aleph.http :as http])
(http/start-server
  (fn [_] {:status 200
           :headers {"transfer-encoding" "chunked"}
           :body (java.io.File. "/path/to/file")})
  {:port 2018 :compression? true})

The raw response looks like

Transfer-Encoding: chunked
Server: Aleph/0.4.6
Date: Sun, 30 Dec 2018 02:36:44 GMT
Connection: Keep-Alive
content-length: 637315352

2000
<content of the first chunk>

:compression? set to true makes the server to include ChunkedWriteHandler onto the pipeline, so the file will be sent using send-chunked-body which implicitly adds Content-Length header. HttpResponseEncoder encodes chunks produced by HttpChunkInput with chunked coding rules (as the presence of the appropriate header dictates to do it). It doesn't cause any issues for a lot of clients, but following RFC2616

3.If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
if these two lengths are different (i.e., if a Transfer-Encoding
header field is present).

I think we need to check if this header is set explicitly before setting Content-Length. Unfortunately It's not very intuitive way of managing encodings, but I feel like removing explicitly set header would be even more confusing than not adding a new one. Also, we probably need to ensure the header is set when sending chunked body.