Here is a PR for a reset state: https://github.com/http2/http2-spec/pull/700/files?diff=split All the conditional behaviour within the close state indicates that it is really multiple states, so this pull request moves the conditional behaviour to the new "reset" state. Then rather than use "a short period" to end the conditional behaviour, I have made the RST_STREAM be acknowledged so we don't have to guess when the peer has seen the reset. On 23 January 2015 at 12:26, Greg Wilkins <gregw@intalio.com> wrote: > > On 23 January 2015 at 12:13, Greg Wilkins <gregw@intalio.com> wrote: > >> We could introduce a RESET state, which means that CLOSE will always be >> entered gracefully and there will be no late packets. RESET could then >> have defined timeout before entering CLOSE. > > > Actually, if we made RESET an acknowledged frame, then we could avoid the > timeout completely as once you have both sent and received a RESET you can > enter close gracefully. > > I know it is late to be hammering on this bugbear, but I'll prepare a PR > none the less. > > cheers > > > > -- > Greg Wilkins <gregw@intalio.com> @ Webtide - *an Intalio subsidiary* > http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that > scales > http://www.webtide.com advice and support for jetty and cometd. > -- Greg Wilkins <gregw@intalio.com> @ Webtide - *an Intalio subsidiary* http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales http://www.webtide.com advice and support for jetty and cometd.
Received on Friday, 23 January 2015 13:27:58 UTC