<div dir="ltr"><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">Hey,</p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">I've been haunted by this for quite some time, seen it in different deployments, and think might make for some good ol' mailing list discussion.</span></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">When</p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">- using keep-alive connections to a backend service (eg php, rails, python)<br>- this backend needs to be updatable (it is not okay to have lingering workers for hours or days)<br>- requests are often not idem-potent (can't repeat them)</span></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">current deployments need to close the kept-alive connection from the backend-side, always opening up a race condition where nginx has just sent a request and the connection gets closed. This leaves nginx in limbo not knowing if the request has been executed and can be repeated.</p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">When using keep-alive connections the only reliable way of closing them is from the client-side (in this case: nginx). I would therefor expect either</span><br></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">- a feature to signal nginx to close all connections to the backend after having deployed new backend code. </span></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">- an upstream keepAliveIdleTimeout config value that guarantees that kept-alive connections are not left lingering indefinitely long. If nginx guarantees it closes idle connections after 5 seconds, we can be sure that 5s+max_request_time after a new backend is deployed all old workers are gone.</span></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">- (variant on the previous) support for a http header from the backend to indicate such a timeout value. It's funny that this header kind-of already exists in the spec <</span><a href="https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#keep-alive" target="_blank">https://tools.ietf.org/id/draft-thomson-hybi-http-timeout-01.html#keep-alive</a>><span style="line-height:1.5">, but in practice is implemented by no-one.</span></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">The 2nd and/or 3rd options seem most elegant to me. I wouldn't mind implementing myself if someone versed in the architecture would give some pointers.</p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px"><span style="line-height:1.5">Best regards,</span><br></p><p style="color:rgb(33,33,33);font-family:"helvetica neue",helvetica,arial,sans-serif;font-size:13px">- Emiel</p>BTW: a similar issue should exist between browsers and web servers. Since latency is a lot higher on these links, I can only assume it to happen a lot.</div>