http2client: add interface 'close_conn()'

[chenbd]

No description provided.

[kazuho]

Thank you for the PR. Yes, we should better have an interface that allows us to gracefully shutdown HTTP/2 client-side connections.

In the long run, I think we should create a function that initiates the destruction of the entire h2o_httpclient_connection_pool_t. That function should initiate close of all client-side HTTP/2 and HTTP/3 connections.

But that requires refactoring of existing code, because at the QUIC / HTTP/3-side, we have and use a function that closes all QUIC / HTTP/3 connections irrespective of them being server-side or client-side.

Therefore, I like the proposed approach of defining a function that closes each client-side HTTP/2 connection.

[kazuho]

I'm not sure if we need to use a callback when the object that we are dealing is already an HTTP/2-specific type.

Maybe create an external function like h2o_httpclient__h2_initiate_close?

[chenbd]

Thanks for the review.
I will add commits according to your comments.

[kazuho]

@chenbd Thank you for your efforts on this PR.

While I was receiving code, I started wondering about the Last Stream ID that we should send as part of the GOAWAY frame. IIUC this PR sends the largest Stream ID that the client initiated, I think that's incorrect. RFC 9113 states that "the GOAWAY contains the stream identifier of the last peer-initiated stream that was or might be processed on the sending endpoint in this connection".

But then, the question comes to if there is benefit in sending a GOAWAY frame, when we never allow the server to push. The peer is never allowed to open a stream, therefore, there is no ambiguity regarding if we (running as a client) have processed anything.

Therefore, I would like to ask the question: what is the purpose for sending a GOAWAY here? Unless there is a good reason to do so, I think I'm inclined to take no action here.

I'm sorry for the inconvenience being caused but am looking forward to hearing your thoughts. Thank you in advance.

[chenbd]

Thanks for the review.
Your comments gets the point. when issuing the PR, i also wondering whether should encode the GOAWAY frame and send it.
after looks into the rfc, it says endpoints should send it.
An endpoint can end a connection at any time. In particular, an
endpoint MAY choose to treat a stream error as a connection error.
Endpoints SHOULD send a GOAWAY frame when ending a connection,
providing that circumstances permit it..
i think encode the GOAWAY frame and send it is harmless.
The Last-Stream-ID for client case, is meaningless in my opinion. and can be filled with 0.
But also, i think we will not facing issues If skip sending the GOAWAY frame.
So IMO sending GOAWAY seems more reasonable according to rfc, but skip sending it also doesn't result in bad effect.