Implement keep-alive max request hint support

[ronag]

Refs: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive
Refs: nodejs/node#40082

[ronag]

@szmarczak or @dnlup?

[szmarczak]

I can take this one.

[artur-ma]

This is actually pretty tricky I think, u may send a lot of pipelined requests, without even receiving the first response header with a hint.

For example if u open a connection and send 10 piplined requests
only on first response u realize that it actually max=5

[szmarczak]

@artur-ma That's actually a good point! The workaround could be to block until we receive the first response. There still may be a situation where we send 10 pipelined requests and in the third one we get max=4.

@ronag

undici/lib/client.js

Lines 1009 to 1012 in 20ce79f

	} else if (timeoutType === TIMEOUT_IDLE) {
	assert(client[kRunning] === 0 && client[kKeepAliveTimeoutValue])
	util.destroy(socket, new InformationalError('socket idle timeout'))
	}

Do we really need to use the timeout from keep-alive header?

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Keep-Alive

timeout: An integer representing the time in seconds that the host will allow an idle connection to remain open before it is closed. A connection is idle if no data is sent or received by a host. A host may keep an idle connection open for longer than timeout seconds, but the host should attempt to retain a connection for at least timeout seconds.

Here, the timeout is handled by the host. If the host decides the connection times out, it simply disconnects us. I think there's no need to handle the logic for host client-side. Maybe I'm missing something...

[ronag]

Maybe I'm missing something...

Yes you are. The client should not send a request if the server can kill the connection before receiving the message, i.e. there is a race condition here. This is particularly bad with non-idempotent requests.

[ronag]

Regarding pipelining... I thinking having a request limit close to the pipelining depth is very unlikely in practice. I would be fine with having that as a known and documented limitation.

i.e. pipelining is usually < 10 while request limits are usually > 100

[szmarczak]

Having in mind #1031 (review) I think we can close this one?

[artur-ma]

@ronag @szmarczak

Any limit on requests can be enforced by sending
"Connection: close" and closing the connection.

If server is limiting number of requests, then piplined requests that send after "connection: close" will be not handled
what should the client do in this case?

Shouldn't it resend the requests to another connection?

E.g I send to a connection 100 request
on 99 response I got connection: close what will happen will happen with the request #100 ?

[ronag]

Shouldn't it resend the requests to another connection?

We already do this.