HTTP/2 server aborts request when request entity is cancelled

[jrudolph]

As observed in akka/akka-grpc#1081.

Hard to say if we should call this a bug. We should probably better document the semantics of certain actions in the streaming API.

We have the same difficulty in HTTP/1.1 as well.

In general, there's no way to stop the incoming request entity stream once it has started. So, the current semantics is:

• on cancellation abort request
• if you want to answer the request, you need to manually ignore the remaining data (or use discardEntityBytes in the first place which also drains and ignores the remaining data.

For HTTP/1.1, the only solution to keep the connection open after half-reading a request is to drain the remaining data.

For HTTP/2, we have an additional (theoretical?) option of just stopping to read the incoming data when the request entity stream is cancelled, the go on with streaming out the response and only after the response has been streamed out and some time has been spent in HalfClosedLocal state, we finally reset the stream to notify the peer that we are not interested in the remaining data. The problem with that solution is that it might hit corner cases in the peer's state handling: leaving the request entity hanging but otherwise completing the request/response cycle and then resetting it in the end. This seems like an uncommon sequence of events.

An alternative would be to add another config option drainRequestEntityOnCancellation which would make sure the remaining entity data is read and discarded even when the stream has been cancelled.