Re: GOAWAY and proxies (#458)

On Fri, May 2, 2014 at 4:10 PM, Daniel Sommermann <dcsommer@fb.com> wrote:

>  On 05/02/2014 03:30 PM, William Chan (陈智昌) wrote:
>
> The way our code works right now is, on receipt of a GOAWAY, we put
> ourselves in a lame duck mode and kill all streams above the last accepted
> stream id with an error code to retry them. If we're already in the lame
> duck mode, great. We don't track anything about previous accepted stream
> ids.
>
>
> Yeah, this is how I am hoping most clients are implemented.
>

Yes, I wish all clients were implemented like Chromium :P


>
> I'm not completely sold on needing any solution here
>
>
> Is it because you perceive the problem to be small and not worth the text
> or that there is no problem? I'd argue strongly against both from
> experience. I am pretty sure all 1.1 to 2.0 intermediary implementations
> will run into this issue to varying degrees. It'd be better to have a
> standard way to deal with it and avoid the surprise factor and reinventing
> the wheel for new deployments.
>

In spec cleanliness maybe it makes sense. Do we think we'll have many 1.1
to 2.0 intermediaries? Maybe in the non-browser case? And maybe for IE if
they support 2.0 in the clear? But Firefox and Chromium will go over TLS,
so I just kinda wonder how important this is in practice. I dunno. Just
saying I'm not completely sold, but if you and others definitely want it,
then I'm fine letting it in.


>
>
> On 05/02/2014 03:30 PM, William Chan (陈智昌) wrote:
>
> I skimmed this PR, but haven't read everyone's comments :) So here's my
> uninformed response.
>
>  The way our code works right now is, on receipt of a GOAWAY, we put
> ourselves in a lame duck mode and kill all streams above the last accepted
> stream id with an error code to retry them. If we're already in the lame
> duck mode, great. We don't track anything about previous accepted stream
> ids. This is a key property that I'd like to see preserved. Another way of
> framing that is that I'd like not to introduce new connection state
> variables to handle multiple GOAWAYs. Secondarily, I kinda feel like
> DRAINING is more explicit than GOAWAY, so I'd paint it that color if
> anything.
>
>  I'm not completely sold on needing any solution here, but if that's the
> direction the working group wants to go, I wouldn't object too strongly.
>
>
> On Fri, May 2, 2014 at 3:07 PM, Roberto Peon <grmocg@gmail.com> 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
>> > 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.
>>>
>>
>>
>
>