(For that matter, it doesn’t necessarily need to burn a frame type – define a setting as being whether the peer knows it intends to kill the connection shortly. It’s zero when unset, flipped to any non-zero value if the recipient needs a back-up plan. That also retains the server’s ability to change its mind, and the ACK means the server has a good gauge of when it’s safe to start sending GOAWAYs….) From: Roberto Peon [mailto:grmocg@gmail.com] Sent: Monday, March 23, 2015 1:03 PM To: Martin Thomson Cc: Mike Bishop; HTTP Working Group Subject: Re: GOAWAY clarification Oh yea! -=R On Mon, Mar 23, 2015 at 12:56 PM, Martin Thomson <martin.thomson@gmail.com<mailto:martin.thomson@gmail.com>> wrote: Thanks Mike, On 23 March 2015 at 11:54, Mike Bishop <Michael.Bishop@microsoft.com<mailto:Michael.Bishop@microsoft.com>> wrote: > One inconsistency in the revised text: You still say at line 2444 that initiating new requests "is inadvisable." It's not just inadvisable, it's MUST NOT at line 2353. Fixed. > I'll also note that the seamless hand-off is a perfect reason for the DRAINING frame extension that was also floated during that discussion -- DRAINING could be defined as a hint that the client should spin up a secondary connection because a GOAWAY is coming soon. No harm if the client doesn't understand or obey it -- the loss is strictly its own. That sounds like a great plan to me. I look forward to someone proposing this extension some day.
Received on Monday, 23 March 2015 22:04:05 UTC