Sent from my iPhone
> On May 30, 2022, at 16:21, Ruediger Pluem <rpl...@apache.org> wrote:
>
>
>
>> On 5/27/22 7:33 PM, Eric Covener wrote:
>> People might recall an event bug where keepalive connections might be
>> closed up to 200ms early (r1874350).
>>
>> I was recently looking at something with $bigco hat on where (IIUC) a
>> slow TTFB for a proxied request causes TCP congestion to kick in and
>> makes even a relatively short response sit in the write buffer.
>>
>>> From the behavior, it appears the browser is:
>>
>> 1) willing to use nearly every millisecond of the advertised KeepAlive
>> time for reusing a connection from its pool
>> 2) starts counting from when the response is complete
>> 3) can't be asked to use Expect: 100-continue on an XHR POST
>> 4) leaves error handling up to the caller and doesn't give it a ton of
>> feedback
>>
>> This results in Apache starting the keepalive countdown "tens" of
>> milliseconds early while the last bytes of the response are in the
>> queue. If we get unlucky, a POST and a FIN cross in the night on a
>> subsequent request.
>>
>> These types of investigations can be really painful. Is there any
>> harm in allowing the server to act like "KeepAliveTimeout 5" is e.g.
>> "KeepAliveTimeout 5200ms".
>>
>> If this fudge buffer existed as an addl directive (rather than a trick
>> documented in KeepAliveTimeout) , would it be reasonable as a non-zero
>> default to discourage this race?
>>
>
> In the end you want to get to a KeepAlive we announce to the client and
> a KeepAlive which is longer than that that we execute.
> My understanding of keepalive is that the client cannot take for granted
> that a connection is really kept alive for as long as it was announced by
> the server (it SHOULD be but there seems no MUST) and in fact we close
> keepalive
> connections if get too busy and keeping these would prevent us from accepting
> new connections.
> Hence I think the issue will not be fixed in all situations.
> I am willing to have this possibility, I guess best by adding an additional
> amount of grace to the KeepAliveTimeout configurable by a directive, but I
> think
> it should be zero by default to avoid confusion unless the behavior you
> report above
> is widespread.
>
> Regards
>
> Rüdiger
