Title: Envoy too strict about transfer-encoding & content-length
Description:

Envoy version: v1.11.2

A service in one of our clusters sometimes returns invalid http1.1. responses that contain both a transfer-encoding: chunked and content-length headers (the content-length is not even 0) which is clearly wrong. Envoy then rejects the response, increments the envoy.cluster.upstream_cx_protocol_error counter and returns a 503.

However, looking at the RFC-2616 section-4.4, it reads:

...If a message is received with both a Transfer-Encoding header field and a Content-Length header field, the latter MUST be ignored.

It seems that this should not be a protocol error, maybe Envoy should ignore the content-length (maybe even strip it out), and forward the response to the downstream.

Thoughts?