Content-Length header gets overridden

[danschultzer]

Content-Length header gets overridden

[mtrudel]

I actually have a few things on the backlog to refine this behaviour (mostly stemming from this issue).

• If a content-length header is set when a user called send_chunked/2, just send a non transfer-encoded response body out as bare bytes as the user calls chunk/2 (this is already what we do for HTTP/2, which doesn't do transfer-encoding)
• I have to verify that we're doing the right thing with sending a content-length header for HEAD/304 (where we MAY send it) and 204 (where we MUST NOT send it)

[danschultzer]

Oh I get it now. The body is not returned for HEAD request as expected. I assume the body is necessary to set to calculate the right length depending on the compression?

[danschultzer]

Ok, I figured out the issue I had. Bandit does need the body to calculate length, can't just set it, makes sense. Also my HTTP client was accepting gzip, Bandit responded accordingly when I was simulating streaming from S3. Setting http_options: [compress: false]] makes this work like AWS. All good, got confused how this was supposed to function 😄