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

Re: GOAWAY and proxies (#458)

From: Daniel Sommermann <dcsommer@fb.com>
Date: Fri, 2 May 2014 15:24:57 -0700
Message-ID: <53641B39.6080401@fb.com>
To: Roberto Peon <grmocg@gmail.com>, Martin Thomson <martin.thomson@gmail.com>
CC: "William Chan (ι™ˆζ™Ίζ˜Œ)" <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
This is already handled in the spec in 6.8:

"Servers SHOULD NOT increase the value they send in the last stream 
identifier, since this would cause clients to abandon automatic retry of 
requests if a GOAWAY frame is lost"

On 05/02/2014 03:07 PM, Roberto Peon wrote:
> 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.
> -=R
> On Fri, May 2, 2014 at 2:50 PM, Martin Thomson 
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>     On 2 May 2014 14:22, Roberto Peon <grmocg@gmail.com
>     <mailto: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:25:29 UTC

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