-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HCM supports configuring keep-alive headers #33593
Comments
clear_hop_by_hop_headers
cc @alyssawilk @RyanTheOptimist IIRC you worked on the previous hop-by-hop headers removal. |
I think there's a misunderstanding on how keep-alive works If you have upstream ---- Envoy --- client Imagine the client sending request 1 over connection 1. This causes Envoy to fetch connection A upstream. In the response for A, the upstream sends a keep-alive response. This does not apply for connection 1. If the client reuses connection 1 for request 2, it may use a completely different upstream connection. In this case, sending keep-alive is going to result in problematic behavior. |
@alyssawilk You are right, I realize that it is inaccurate to solve this issue by simply not clearing the hop-by-hop headers. Sorry for not updating my understanding of this solution in this issue (already updated now). |
https://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_timeout This nginx directive supports the following configuration: This configuration means that the idle timeout for connections between Nginx and Downstream is 90 seconds, and Nginx will return Because Envoy sets idle_timeout in http_protocol_options, so here we add a setting for the timeout value of keep-alive header in HCM's configuration options. |
This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions. |
Title: *HCM supports configuring keep-alive headers *
Description:
When using a lower version (<5.2) of Java Apache HTTP client, the client will determine how long a connection can be reused based on the
Keep-Alive
header in the backend response.If theKeep-Alive
header is not present in the response, HttpClient assumes the connection can be kept alive indefinitely. If Envoy removes thisKeep-Alive
response header, the client may attempt to reuse a closed connection, resulting in I/O errors.This is due to incorrect implementation of connection reuse mechanism by the client, but in our scenario, such clients are present on numerous old devices and cannot be upgraded. Therefore, we hope that Envoy can support configuring not to remove this response header. This would help us migrate from a large number of Nginx gateways to Envoy gateways.
(The following content is added after modification.)
I realize that it is inaccurate to solve this issue by simply not clearing the hop-by-hop headers. In fact, we need to set the Connection and Keep-Alive headers for the envoy proxy layer in order to adapt to certain special clients, instead of passing through these headers from upstream. However, currently there is no distinction made when mutating response headers whether these headers were added through response_headers_to_add in route config or returned by upstream, which prevents us from setting them.
A reasonable solution that I have considered is to refer to the keepalive_timeout directive in Nginx. Set the idle_timeout to the Keep-Alive Header when handling HTTP/1, but do not set it for HTTP/2 or HTTP/3.
The text was updated successfully, but these errors were encountered: