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

Re: Streams after receiving GOAWAY

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Mon, 16 Nov 2015 19:34:44 +1300
To: ietf-http-wg@w3.org
Message-ID: <56497904.7010606@treenet.co.nz>
On 16/11/2015 12:20 p.m., Glen Knowles 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."
> 
>> 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.
> 

Lets put it another way.

* GOAWAY is used to signal error conditions.

If no such stream ID was ever sent by this client, and the ID is not the
special case 2^31-1 value; then the frame interpretation state has
apparently been corrupted somehow on the server.

The client now authoritatively cannot trust _anything_ seen on that
connection. Its best course of action is termination of that corrupted
connection. Not a graceful shutdown. Immediate termination.

Amos
Received on Monday, 16 November 2015 06:35:46 UTC

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