I've remade the PR as the branch I originally used had some reverted commits in it. Here it is again with some corrections from Scottmitch https://github.com/http2/http2-spec/pull/701 On 23 January 2015 at 14:27, Greg Wilkins <gregw@intalio.com> wrote: > 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. > -- 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 14:40:15 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:48 UTC