Today ConnectionContext.Transport.Output.CompleteAsync() fully closes the connection with both the libuv and managed socket transport. As soon as the transport send loop sees a completed ReadResult, it calls Socket.Shutdown(SocketShutdown.Both) or an equivalent. This prevents the application from reading more from ConnectionContext.Transport.Input even if the other side of the connection did not finish sending data.
Given that ConnectionContext.DisposeAsync() now exists and also fully closes the connection, the contract for ConnectionContext.Transport.Output.CompleteAsync() should change to only close the sending side of the connection. The converse should also be true for ConnectionContext.Transport.Input.CompleteAsync(). DisposeAsync() should continue to fully close the connection after the send loop completes like it does today, and Abort() will continue to immediately terminate the connection.
Today ConnectionContext.Transport.Output.CompleteAsync() fully closes the connection with both the libuv and managed socket transport. As soon as the transport send loop sees a completed ReadResult, it calls Socket.Shutdown(SocketShutdown.Both) or an equivalent. This prevents the application from reading more from ConnectionContext.Transport.Input even if the other side of the connection did not finish sending data.
Given that ConnectionContext.DisposeAsync() now exists and also fully closes the connection, the contract for ConnectionContext.Transport.Output.CompleteAsync() should change to only close the sending side of the connection. The converse should also be true for ConnectionContext.Transport.Input.CompleteAsync(). DisposeAsync() should continue to fully close the connection after the send loop completes like it does today, and Abort() will continue to immediately terminate the connection.