如何处理长时间运行的服务器响应和负载平衡器，将其视为停滞的连接

Question

Case/Assumption:

1. There is a server that is written by someone else.
2. This server has an endpoint GET /api/watch.
3. This endpoint is plain HTTP/1.1
4. This endpoint will write events like

   {type:"foo", message:"bar"}
   

   to the response stream once they appear (one event per line and then a flush).
5. Sometimes this server writes events every second to the output, sometimes every 15 minutes.
6. Between my client and this server there is a third-party Load Balancer which assumes a connection as staling if there is no action on the connection for more than 60 seconds and drops the connection without closing it.
7. The client is written in simple Golang and simply makes a GET request to this endpoint.
8. Once the connection is marked by the LB as staled the client (the same happens to curl, too) is not notified that the connection was dropped by the LB and is still waiting for stuff to receive in the response of the GET request.

So: What are my possibilities to deal with this situation?

What is not possible:

1. Modify the server.
2. Use another server.
3. Use something else than this endpoint and how it is written.
4. Modify the Load Balancer.
5. Use another LB.
6. Leave the LB out of the connection.

Answer 1

15 minutes is an incredibly long quiet period for basic HTTP - possibly better-suited to WebSockets. Short of a protocol change, you should be able to adjust the timeout period on the load balancer (hard to say since you didn't specify what the LB is) to better suit your use case, though not all load balancers will allow timeouts as high as 15 minutes. If you can't change the protocol and can't turn the timeout up high enough, you would have to send keepalive messages from the server every so often (just short of the timeout period, so maybe 55s with your current config, or a little less than the highest timeout period you're able to set on the LB). This would have to be something the client knew to discard, like {"type": "keepalive"} - something easily identifiable on the client side as a "fake" message for keepalive purposes.