"unsupported transfer encoding" error in istio proxy


We are running into a problem with Istio 1.5.0.
We are sending a POST request to a container running in a pod. Let’s say this is app1.
This triggers a POST request from app1 to app2. App2 is running in another container in a different pod. App2 sends the POST response back to app1, and app1 sends a POST response back to the user.
Both pods have the istio-proxy sidecars running for these applications.

The istio-proxy of app1 is generating an unsupported transfer encoding error when receiving the POST response from app1:
[Envoy (Epoch 0)] [2020-04-06 19:27:00.513][24][debug][client] [external/envoy/source/common/http/codec_client.cc:127] [C64] protocol error: http/1.1 protocol error: unsupported transfer encoding

These are the response headers:
HTTP/1.1 201
Set-Cookie: XSRF-TOKEN=; Max-Age=0; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/
Set-Cookie: XSRF-TOKEN=f24efe82-c999-473a-8d50-081553c3d225; Path=/
content-disposition: inline;filename=f.txt
date: Mon, 06 Apr 2020 19:53:54 GMT
x-envoy-upstream-service-time: 12
server: envoy
transfer-encoding: chunked
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
Content-Type: application/json
Transfer-Encoding: chunked


This relates to Envoy version 1.13:
http: blocks unsupported transfer-encodings. Can be reverted temporarily by setting runtime feature envoy.reloadable_features.reject_unsupported_transfer_encodings to false

That workaround works for me, but I’d rather have a definitive solution.
Does envoy not support Transfer-Encoding: chunked at all?
Or does this happen because this header is present twice?

Thanks in advance for your help.
Jasper Misset

1 Like

HI @jmisset
Would it be possible to share the complete workaround?

Many thanks

Hi mvicedo,

The workaround is running the following command:

kubectl exec podname -c istio-proxy – curl -X POST http://localhost:15000/runtime_modify?envoy.reloadable_features.reject_unsupported_transfer_encodings=true

PS - We have changed our container images, instead of running on Apache Tomcat, they now use Undertow. There the problem does not exist (the header only exists once) so this seems like an Apache Tomcat issue.