> Am 29.05.2020 um 11:23 schrieb Ruediger Pluem <[email protected]>:
>
>
>
> On 5/29/20 10:09 AM, Stefan Eissing wrote:
>> Looks good. Now I learned about the "ping" parameter...
>
> Committed as r1878264 with a tweaked comment to make clear what I do.
>
> Getting me to the next possible enhancement. I already had a patch but when
> putting it to the mail I got doubts that it could work
> due to the fact, that in most use cases HTTP/2 is encrypted.
> In AJP a set ping parameter on the worker will also cause an AJP ping to be
> sent as the first thing even on fresh connections and
> we only wait for the timeout set in the parameter for a reply. The idea
> behind this is that the backend might be able to deal with
> a TCP handshake, but not with processing a request, because maybe all
> processing threads / processes on the backend application
> are busy. This way this can be detected quickly and early and we can sent our
> request to a different backend in case of a load
> balancing scenario.
> With HTTP/2 we will likely have a TLS handshake first which likely already
> requires a responding backend application. So it would
> not work to wait only for ping timeout time on a ping reply as we will
> already wait for the timeout set on the socket to get an
> answer to our TLS client Hello. So the idea would be to already lower the
> socket timeout to ping timeout before the TLS handshake
> starts and reset it back after we received the ping from the backend.
> Opinions?
HTTP/2 also has an initial SETTINGS frame handshake. We could use the ping
timeout on the socket until the first NGHTTP2_SETTINGS frame from the backend
arrives on a new connection.
- Stefan
