getRequestBodyChunk should indicate if a chunk is the last one

[edsko]

For streaming calls, clients have two ways of indicating end-of-input to the sever:

NON-EMPTY DATA FRAME 1  <not marked as end-of-stream>
NON-EMPTY DATA FRAME 2  <not marked as end-of-stream>
NON-EMPTY DATA FRAME 3  <marked as end-of-stream>

and

NON-EMPTY DATA FRAME 1  <not marked as end-of-stream>
NON-EMPTY DATA FRAME 2  <not marked as end-of-stream>
NON-EMPTY DATA FRAME 3  <not marked as end-of-stream>
EMPTY DATA FRAME 4 <marked as end-of-stream>

getRequestBodyChunk does not allow servers to differentiate between these two cases; in both cases, we will first get a non-empty bytestring indicating the last piece of data, and then the next call to getRequestBodyChunk will return an empty bytestring. Calling getRequestBodyChunk again to figure out after-the-fact if the previously received bytestring was the final one is not an option, because that call may block. We therefore need a generalization that doesn't just give us a bytestring, but also tells us if that bytestring was marked being the last one.

For an example of where this matters, see well-typed/grapesy#114 .

[edsko]

@kazu-yamamoto This is not a request for you to do anything :) Merely writing this here for the record; I hope to have a chance to fix this myself (but not yet sure when I will get to it).

[kazu-yamamoto]

Please feel free to add a new API which returns both ByteString and EOF.

[kazu-yamamoto]

I'm probably going to create http-semantics library to extract the common parts from http2. #113

The new API should be defined in that library.

[edsko]

I just noticed that there is a non-deterministic failure in my grapesy tests that depend on this feature. Something to do with what happens if a DATA frame sits just at the end of a TCP package or something. I am still investigating. (It means that the end-of-stream Bool is not always dependable at the moment.)

[edsko]

The issue is not with this feature, but rather than the end-of-stream flag is sometimes not set when I'm expecting it to be. I'll keep digging and open an issue or PR when I know more.

[kazu-yamamoto]

The end-of-stream flag can come sololy without stream data.
Do you cover this case?

[edsko]

I do, but on the sending side, for some servers it is important that the end-of-stream flag is not in a separate data frame, but is instead part of the final frame that actually contains data. (I realize that that makes them poor servers, but it's true nonetheless.) So I am careful in the way I use http2 to try and ensure that this happens as expected, and that almost always works, but not always, and I don't understand why, in an otherwise entirely deterministic test. That's the part I'm currently investigating.

Perhaps put another way: just like this feature is about being told when a chunk is the final one when we receive it on the sending side, we must also be able to indicate when a chunk is the final one on the sending side. We can already do that in http2, but it's non-deterministic, and I don't yet know why.