W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: GOAWAY and proxies (#458)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 17 Apr 2014 09:44:27 -0700
Message-ID: <CABkgnnVnes7mo5NWaA=cexRHK4cxD0_7OTQekJh03f5C9149ag@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC