Re: HTTP/2 response completed before its request

I feel that maybe the two directions of a stream should have
independent RSTs, so that we can model more error cases.

An end point can issue an RST for its outbound only, meaning that its
outbound stream is abruptly terminated. Meanwhile its inbound is still
intact, and it is still accepting inbound data.

An end point can also issue an RST for its inbound only, meaning that
it's no longer interested in inbound data, and the peer should stop
sending more data. Meanwhile the outbound is still intact, and it *is*
still writing to the outbound.

Zhong Yu
bayou.io


On Wed, Jul 2, 2014 at 12:06 PM, Willy Tarreau <w@1wt.eu> wrote:
> On Wed, Jul 02, 2014 at 12:31:24PM -0400, Patrick McManus wrote:
>> On Wed, Jul 2, 2014 at 12:04 PM, Willy Tarreau <w@1wt.eu> wrote:
>>
>> > OK thanks for explaining. But I still fail to see the difference. And
>> > upload
>> > and a download are exactly the same, in both cases we're sending a message
>> > body and any party should be free to abort receipt saying it doesn't want
>> > it
>> > anymore.
>> >
>>
>> I agree - you just used the canceled download as an example - so I stayed
>> on track with it as it would be much more common that the scenario in this
>> thread.
>>
>> In the okhttp case the server is the one receiving a stream it might not
>> want. Its state is half-closed-local (because it has already generated the
>> END_STREAM) and from that state it can send a RST_STREAM, NO_ERROR and the
>> client ought to stop uploading stuff when it receives that.
>
> OK so it's more of an implementation issue than a protocol design issue ?
> Then maybe the case should be documented while it's hot so that nobody gets
> trapped again.
>
> Thanks
> Willy
>
>

Received on Wednesday, 2 July 2014 19:34:56 UTC