Where we're sending an Informational (1xx) or No Content (204) response, per the RFC we should never set a Transfer-Encoding header, regardless of what the client supplied in its TE header.

See https://tools.ietf.org/html/rfc7230#section-3.3

A server MUST NOT send a Transfer-Encoding header field in any response with a status code of 1xx (Informational) or 204 (No Content).

The current behaviour causes some clients to hang if they provide TE: chunked, for example cURL and Python's Requests library.

tiny-http sends a 204 No Content response that looks like this:

0000   48 54 54 50 2f 31 2e 31 20 32 30 34 20 4e 6f 20   HTTP/1.1 204 No 
0010   43 6f 6e 74 65 6e 74 0d 0a 53 65 72 76 65 72 3a   Content..Server:
0020   20 74 69 6e 79 2d 68 74 74 70 20 28 52 75 73 74    tiny-http (Rust
0030   29 0d 0a 44 61 74 65 3a 20 57 65 64 2c 20 33 31   )..Date: Wed, 31
0040   20 4d 61 72 20 32 30 32 31 20 31 31 3a 30 36 3a    Mar 2021 11:06:
0050   30 37 20 47 4d 54 0d 0a 54 72 61 6e 73 66 65 72   07 GMT..Transfer
0060   2d 45 6e 63 6f 64 69 6e 67 3a 20 63 68 75 6e 6b   -Encoding: chunk
0070   65 64 0d 0a 0d 0a                                 ed....

Since there's no body, we don't send the terminating 0\r\n\r\n chunk and so the clients can wait forever.