[quicwg/base-drafts] Writing after closed frame enqueued (#777)

ekr <notifications@github.com> Mon, 18 September 2017 19:28 UTC

Date: Mon, 18 Sep 2017 12:28:27 -0700
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab826968d5cdc954b4033302ff16c508ca7a76788f92cf0000000115d7e05b92a169ce0f69d2d9@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/777@github.com>
Subject: [quicwg/base-drafts] Writing after closed frame enqueued (#777)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_59c01e5bca998_1d83f3fd6a41c4f3471768"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/wLFfZ9HhRZsgAK_4hTtYrUfUmTI>

I'm not sure if this belongs in the QUIC spec, but I had to handle it specially in Minq so I thought I would mention it.

The current text shows the transition from OPEN to HALF_CLOSED (LOCAL) happening when you send a FIN. However, if you think of this from an API perspective, that's not quite what you want. Consider the case where you have a stream flow control window of 1000. You write 999 and then 1000-1999, and then call stream.Close(). At this point, you have in queue:

``` 
  [0-999] (sent, maybe un-acked)
  [1000-1999] (not-sent)
  [2000: FIN] (not sent)
```

You're still in OPEN because you haven't sent the FIN, but the implementation should stop you from doing another Write() at this point.




-- 
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/777

[quicwg/base-drafts] Writing after closed frame e… ekr
Re: [quicwg/base-drafts] Writing after closed fra… Martin Thomson
Re: [quicwg/base-drafts] Writing after closed fra… Martin Thomson
Re: [quicwg/base-drafts] Writing after closed fra… Martin Thomson