Re: GOAWAY and proxies (#458)

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.
>
>