Re: GOAWAY and proxies (#458)

Just to be clear, this is a problem with HTTP/1.1 today, right? HTTP/2
improves on the situation with GOAWAY which allows the server, in graceful
shutdown, to explicitly indicate which streams have been "accepted", so the
client can safely retry. In your example, a proxy probably won't buffer the
request, so it can't retry itself. I'd say that RST_STREAM with
REFUSED_STREAM would solve your issue, but I see that the client<=>proxy
connection is HTTP/1.X, so that facility is not available.

When I think about what Chromium would upon receipt of a DRAINING frame, I
don't know. Unless we were to open up a new connection, there's not much we
could do, and we'd just send requests anyway. But yeah, from a load
balancing proxy talking to a set of HTTP/2 backends, I can see the utility
here. My inclination is to push back on this unless more proxy vendors
clamor for this. What do you do today in this situation? It seems like you
could build this draining semantic at the application layer on top of the
proxy<=>backend connections, by using magic path handlers
(/doyouwanttoacceptrequests), which indeed is how I would imagine doing it
with HTTP/1.X connections to the backends. This type of polling isn't
exactly elegant, but mostly works today.

So yeah, I'm open to it, but need more convincing.


On Mon, Apr 21, 2014 at 9:45 AM, Daniel Sommermann <dcsommer@fb.com> wrote:

> I'm very interested in hearing from proxy implementors doing HTTP/1.1
> client to HTTP/2 or SPDY server conversion regarding issue #458. In our
> experience at Facebook, this becomes a significant source of user-visible
> errors during origin server restarts.
>
>