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

Re: GOAWAY and proxies (#458)

From: Roberto Peon <grmocg@gmail.com>
Date: Fri, 2 May 2014 15:07:35 -0700
Message-ID: <CAP+FsNcHrEr02r5QhhH_=8OB_f7xSjX72zrP2vuV3irUeDXT4A@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Daniel Sommermann <dcsommer@fb.com>, William Chan (ι™ˆζ™Ίζ˜Œ) <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
Agreed, but the current text doesn't allow for that to be determined with
any certainty, since there may be a subsequent GOAWAY frame which may alter
the last-potentially-processed-stream in *either* direction (as written).

The solution to that part is simple-- GOAWAY can only give a number that is
less than that which was sent before, thus indicating that a larger portion
of the stream-space was *not* processed.

Separately, I'd be shocked if many U-As actually did anything with
subsequent GOAWAYs, however-- the logic for cancelling the retries, etc.
would get very hairy very quickly if the assumption at time T was different
than T+1 and one had already acted upon the information at time T.

I still like DRAINING better for the purpose of getting clients to
reconnect, regardless of what happens with GOAWAY.

On Fri, May 2, 2014 at 2:50 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 2 May 2014 14:22, Roberto Peon <grmocg@gmail.com> wrote:
> > As written now, the receiver of GOAWAY has zero certainty about which
> > streams were successfully processed as the server gets to change its mind
> > and isn't limited to simply changing the number in one direction.
> The purpose isn't to indicate what is successfully processed.  It's to
> indicate what _might have been_ processed.
Received on Friday, 2 May 2014 22:08:02 UTC

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