- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 17 Apr 2014 09:44:27 -0700
- To: Daniel Sommermann <dcsommer@fb.com>
- Cc: Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 17 April 2014 07:41, Daniel Sommermann <dcsommer@fb.com> wrote: > I opened https://github.com/http2/http2-spec/issues/458 to track this. My > proposal is to add a DRAINING frame rather than rely on Alt-Svc as Alt-Svc > for shutdown would require all webservers to keep track of alternates. > Tracking alternates falls naturally under the work of the proxy and not the > webserver in my opinion. For the record: --- I first brought this up in http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0158.html but I wanted to open an issue to track this as I believe this is a design flaw with HTTP/2 as it is today. Consider an HTTP/1.1 connection to a proxy that speaks HTTP/2 to the server. If the server needs to shut down, it will send a GOAWAY acknowledging the last request it processed. However, there is a race condition where a request could be in flight or queued. When the server eventually sees the delayed requests, it will not process it and the proxy will eventually return an error (most likey 5xx) to the client. Requiring proxies to buffer the request in order to replay for this case is not feasible. One solution is to have the server send an ALTSVC frame, but this is not ideal as it implies each server must keep track of a list of alternatives. It may not make sense for the origin server itself to maintain this (potentially quickly changing) list. Another solution is to allow acknowledging unreceived streams in the GOAWAY. For instance, the server could acknowledge last-stream-id plus SETTINGS_MAX_CONCURRENT_STREAMS. This might work in practice, but seems hacky. Another (and in my view best) solution would be to introduce a two phase shutdown mechanism. Suggested language: "If a server needs to shut down for maintenance, the server SHOULD immediately send a DRAINING frame on all its client connections to indicate that it will soon shut down. This allows the client to stop issuing new requests and avoids unnecessary retries. After a reasonable amount of time, the server SHOULD send a GOAWAY with status NO_ERROR on all its connections and then close the connection. Clients MAY may open new connections to the server after receiving a DRAINING frame." --- HTTP/2 has a significantly higher investment per connection than HTTP/1.1, which is why these mechanisms are suddenly hugely important. What would have just been executed as a connection close in HTTP/1.1 now has too much collateral loss. I think that some text on this issue is definitely appropriate. As for solutions, I actually like the GOAWAY hack. It's basically the same as the DRAINING frame that you propose, without the additional mechanism. It's last stream + 2*max concurrent, BTW, and that won't catch streams from clients that decide to skip numbers, but I don't think that's worth worrying about. In practice, you could set the last stream ID to 2^31-1 and it would have the same effect. Maybe we could also add a new error code to accommodate the use case, though I'll note that NO_ERROR seems like a pretty good fit already; maybe a last stream ID of 2^31-1 is a sufficient signal. Maybe we also want to allow for a second GOAWAY to allow for error handling during this shutdown process too.
Received on Thursday, 17 April 2014 16:44:55 UTC