Setup:
+------+ +------------+ +------------+ +------+
|client|----->|client-proxy|----->|server-proxy|----->|server|
+------+ +------------+ +------------+ +------+
- Run
docker-compose up
- Run
time docker exec -it envoy-respect_expected_rq_timeout-issue_client_1 curl client-proxy:9001/test
- The request should time out in 15s
- server-proxy logs show an inbound request with the header:
'x-envoy-expected-rq-timeout-ms', '120000'
- server-proxy logs show an outbound request with the header:
'x-envoy-expected-rq-timeout-ms', '15000'
, which ignores the 120000 from the egress Envoy.
Additionally, adding a route timeout to the ingress Envoy will update the timeout of the request to the server, also disregarding the value in x-envoy-expected-rq-timeout-ms
.
Tested on versions going back to v1.14.1
- Run
docker-compose up
- Run
time docker exec -it envoy-respect_expected_rq_timeout-issue_client_1 curl -vH 'x-envoy-upstream-rq-timeout-ms: 10' client-proxy:9001/test
- The request should time out in < 1s
- client-proxy logs show an outbound request with the header:
'x-envoy-expected-rq-timeout-ms', '10'
- server-proxy logs show an inbound request with the header:
'x-envoy-expected-rq-timeout-ms', '10'
- server-proxy logs show an outbound request with the header:
'x-envoy-expected-rq-timeout-ms', '15000'
, which ignores the 120000 from the egress Envoy.
The behavior of the client proxy is what's expected. The upstream rq header comes in, and the client-proxy uses that as the timeout for the request to the server-proxy.