Philip Sanetra

I experience this issue on the envoy pods, too. Usually the envoy `/ready` endpoint returns a valid response within `< 100ms`, but sometimes its response time takes over `5 seconds`....

In my case I forgot to enable policies for ingresses. So the following did work: ```yaml policy: applyToIngress: true request-headers: set: X-Forwarded-Port: "443" ``` Still it would probably be nice...

Note: The issue seems to appear with `HTTP 1.1`, too. So setting `default-http-versions` to support `HTTP 1.1` exclusively does not work as a workaround.

@sunjayBhatia Can I support you in debugging this issue? I definitely get responses from the wrong backend after an initial connection. I even still receive responses from the wrong backend...

> As a workaround as well, you could use the max-requests-per-connection Listener setting https://projectcontour.io/docs/1.27/configuration/#listener-configuration (though this is a global setting so maybe not ideal) This works for us as a...

@sunjayBhatia as expected the workaround is really adding a lot of overhead, especially on many small requests, [especially as chrome allows only 6 concurrent connections per origin](https://bugs.chromium.org/p/chromium/issues/detail?id=12066). So it would...

We would appreciate the option to set a global upstream request timeout as well.

Do you have a use case where you need to skip the emission of the default value? Is it not possible to solve these cases with the `skip` operator?

Hi @qvistgaard, sorry for answering this late. I missed this issue somehow :-/ > Markdown changelog only includes feat and fix, I think it should include everyting Yes I also...

@qvistgaard thank you for the reminder. I will think about this later today. I think it should be possible to solve that issue without this special flag. Maybe you can...