Re: Streams after receiving GOAWAY

On 16 November 2015 at 09:20, Glen Knowles <gknowles@ieee.org> wrote:

> >I apologise, I wasn’t clear enough. You could have had this flow:
> >
> >Client: PREAMBLE + SETTINGS
> >Server: SETTINGS + SETTINGS(ACK)
> >Client: SETTINGS(ACK)
> >Server: GOAWAY(last_stream_id=101)
> >
> >Any client that complies with RFC 7540 will see this GOAWAY and
> immediately
> >refuse to open further streams.
>
> Which is a correct outcome, since the server wants to gracefully close the
> connection, otherwise it wouldn't've sent the GOAWAY(no_error).
>
> >In the above example, the server is acting incorrectly (last_stream_id
> does
> >not correspond to a stream it has even seen, let alone begun to process).
>
> I get the feeling that you're not familiar with the graceful shutdown
> language, or perhaps I haven't been clear.
>
> "A server that is attempting to gracefully shut down a
> connection SHOULD send an initial GOAWAY frame with the last stream
> identifier set to 2^31-1 and a NO_ERROR code.  This signals to the
> client that a shutdown is imminent and that initiating further
> requests is prohibited.  After allowing time for any in-flight stream
> creation (at least one round-trip time), the server can send another
> GOAWAY frame with an updated last stream identifier."
>
>
​..."initiating further requests is prohibited."

This section means that 2^31-1 is a magic number, and if you (the client)
get it in your GOAWAY, you might then get another GOAWAY with a real
last-stream-id, once the server is actually done receiving streams. It
doesn't mean the client can ignore the first GOAWAY once it sees it.


> > MUST NOT   This phrase, or the phrase "SHALL NOT", mean that the
> definition
> is an absolute prohibition of the specification.
>
> I'm well aware of what a normative MUST NOT means, I'm arguing that it's
> use
> in this case is to strong (or to general) - in no small part because
> violating
> it is undetectable by the peer.
>
>
​What's to detect? It's a signal: if you get a GOAWAY with a
last-stream-id, you can safely retry any message with a greater stream id,
even if it's non-idempotent.

Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/