Re: [quicwg/base-drafts] ambiguity on reaction to RST_STREAM (#1671)

[Mike Bishop <[e-mail]>]

This is actually very like what we wrestled with in #1643.

Consider the extreme case and work backward:
- **RST_STREAM is received after application has already read the entire stream data.**  Application might not ever realize there was a RST -- it's already consumed everything and moved on.
- **RST_STREAM is received after transport has received all data, but application hasn't read it to completion.**  You can either surface all the data to the application (turns into previous case) or drop the unread data and begin returning a read error.
- **RST_STREAM is received while data is outstanding.**  You can either surface the error when the application's reads hit a gap, or drop the unread data and begin returning a read error immediately.

Frankly, I'm comfortable with that being an implementation decision.  When you send a RST_STREAM, you're accepting some ambiguity about exactly what makes it to the other side.  In HTTP, we resolved that by saying that if you've potentially sent enough data for the other side to act on and you don't want to see the response, you need to send a STOP_SENDING at the same time.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/1671#issuecomment-413655998