Thank you for working on the issue.

Actually there's no need to grab content-length in h2o_hpack_parse_response_headers at this time, so removed it.

I am not sure if that is the correct solution. Our semantics is to have the excepted content-length stored in h2o_req_t::res.content_length. Compress handler uses that to determine if we need to compress the output on the fly.

IMO, we should follow the semantics, and also handle inconsistency between the content-length and the actual size of the response under the semantics we have established in #1490.

Discussed. We set res.content_length in proxy.c. There is no need to handle content_length as a special header in parse_response.

IMO, we should follow the semantics, and also handle inconsistency between the content-length and the actual size of the response under the semantics we have established in #1490.

@i110 will have a follow-up commit to address this issue.