Send GOAWAY on client shutdown

[ejona86]

The HTTP/2 spec encourages sending GOAWAY before dropping the connection. GOAWAY is necessary for "graceful" shutdowns.

When error handling:

Endpoints SHOULD send a GOAWAY frame when ending a connection, providing that circumstances permit it.

In the GOAWAY frame description section:

Endpoints SHOULD always send a GOAWAY frame before closing a connection so that the remote peer can know whether a stream has been partially processed or not.

.

A GOAWAY frame might not immediately precede closing of the connection; a receiver of a GOAWAY that has no more use for the connection SHOULD still send a GOAWAY frame before terminating the connection.

When discussing connection management:

When either endpoint chooses to close the transport-layer TCP connection, the terminating endpoint SHOULD first send a GOAWAY (Section 6.8) frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks.

[dsymonds]

Dupe of #147.

[ejona86]

#147 is server-side, this is client-side.

[pires]

Any update on this?

[shuaichang]

+1, currently seems there's no way to close a clientconn gracefully, the transport is not accessible from outside of clientconn, so it's not possible to send Goaway to the transport

[dfawley]

@shuaichang is the current behavior causing problems for you? IIUC, this is a pretty minor issue in that it would allow the server to more quickly clean up when a client disconnects, but is not a high priority issue.

Maybe you're more interested in #1104?

[shuaichang]

We implemented a client conn cache and sometime need to evict some conn out of cache and close it, without a graceful Close method, we will have implement something based on timeout, which is sub-optimal comparing to the grpc transport.GracefulClose. Seems the function is there, but not exported out of the package

[dfawley]

@shuaichang thanks for the explanation. That feature request is #1104, not this issue. This issue is about sending an HTTP2 GOAWAY frame before closing a connection, regardless of whether we allow existing streams on that connection to continue.

[shuaichang]

Cool, I'll +1 in that issue