You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In #3841 (see also #1778), we introduce per-stream idle timeouts. However, these apply at the route level. In order to know the per-route timeout, we need to have decoded headers already. It's possible that streams may idle hang prior to request header completion.
A simple solution is to just do a global stream idle timeout as well, that can be overridden once the per-route idle timeout is determined.
The text was updated successfully, but these errors were encountered:
This is a followup to envoyproxy#3841, where we introduce HCM-wide stream idle timeouts. This has two effects:
1. We can now timeout immediately after stream creation, potentially before receiving request
headers and routing.
2. A default timeout can be configured across all routes. This is overridable on a per-route basis.
The default and overriding semantics are explained in the docs. Also added as a bonus some docs
about how timeouts interact more generally in Envoy.
Fixesenvoyproxy#3853.
Risk Level: Low. While there is some change to the per-route vs. HCM wide semantics for stream idle
timeouts, it's not anticipated this feature is in common use yet (it's only a couple of days since
landing), and the caveats in envoyproxy#3841 with the new 5 minute default timeout should already apply.
Testing: Unit/integration tests added.
Signed-off-by: Harvey Tuch <htuch@google.com>
This is a followup to #3841, where we introduce HCM-wide stream idle timeouts. This has two effects:
1. We can now timeout immediately after stream creation, potentially before receiving request headers and routing.
2. A default timeout can be configured across all routes. This is overridable on a per-route basis.
The default and overriding semantics are explained in the docs. Also added as a bonus some docs
about how timeouts interact more generally in Envoy.
Fixes#3853.
Risk Level: Low. While there is some change to the per-route vs. HCM wide semantics for stream idle
timeouts, it's not anticipated this feature is in common use yet (it's only a couple of days since
landing), and the caveats in #3841 with the new 5 minute default timeout should already apply.
Testing: Unit/integration tests added.
Signed-off-by: Harvey Tuch <htuch@google.com>
In #3841 (see also #1778), we introduce per-stream idle timeouts. However, these apply at the route level. In order to know the per-route timeout, we need to have decoded headers already. It's possible that streams may idle hang prior to request header completion.
A simple solution is to just do a global stream idle timeout as well, that can be overridden once the per-route idle timeout is determined.
The text was updated successfully, but these errors were encountered: