thanks for considering the feedback!
What i was trying to explain is Server not giving up is never a good thing under congestion.
This is why in ip switches they drop packet when the outbound queue is full. And letting the caller retry sending the packet.
When there is no congestion it’s ok for the server to not timeout at all and wait for the queue to drain and let the client decide when to close the tcp connection.
but when there is congestion you don’t want the queue inside the server to get too long. Because the server ( including caddy) might be behind a tcp load-balancer so it’s better for the client to queue it’s request inside another Caddy instance that is less busy.
This is why in ip switches they drop packet when the outbound queue is full. And letting the caller retry sending the packet.
When there is no congestion it’s ok for the server to not timeout at all and wait for the queue to drain and let the client decide when to close the tcp connection.
but when there is congestion you don’t want the queue inside the server to get too long. Because the server ( including caddy) might be behind a tcp load-balancer so it’s better for the client to queue it’s request inside another Caddy instance that is less busy.
feel free to reach out to me at [email protected]
I would be happy to try to add it to Caddy if you are interested