W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Streams after receiving GOAWAY

From: Glen Knowles <gknowles@ieee.org>
Date: Sun, 15 Nov 2015 15:20:22 -0800
Message-ID: <CAJCH0yCW11LKHb9Y8KXRpmMTDKM6isNaFjGcZWqLSeh4xuOHvw@mail.gmail.com>
To: Cory Benfield <cory@lukasa.co.uk>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
>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."

> 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.
Received on Sunday, 15 November 2015 23:20:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC