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

Re: GOAWAY and proxies (#458)

From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Mon, 21 Apr 2014 15:58:23 -0700
Message-ID: <CAA4WUYhZ7BPeVT0wpujpHp8aVKHgHx-CCo_PEVz5WUjVNaMoLg@mail.gmail.com>
To: Daniel Sommermann <dcsommer@fb.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Roberto Peon <grmocg@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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.
>
>
Received on Monday, 21 April 2014 22:58:50 UTC

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