Re: Streams after receiving GOAWAY

> On 15 Nov 2015, at 10:24, Glen Knowles <gknowles@ieee.org> wrote:
> 
> I'm about to deliberately violate the letter of a MUST NOT because I believe it's overly strict.
> 
> "Receivers of a GOAWAY frame MUST NOT open additional streams on the connection..."
> 
> When the client gets a GOAWAY it will immediately start establishing a new connection, continue issuing new requests up to the reported last id, and close the old connection when it either has a new connection or has used all the reported streams.
> 
> The goal is to avoid suspending requests in a high volume server to server environment while waiting for new connections. I don't see how it conflicts with any conforming implementation, am I missing something?


The client conflicts with *any* conforming implementation because it ignores the section of RFC 7540 that you just quoted. You’re not just violating the letter of that MUST NOT, you’re violating the spirit of it too, which is indicated in the first paragraph of that section of the spec:

> GOAWAY allows an endpoint to gracefully stop accepting new streams while still finishing processing of previously established streams.

GOAWAY is not intended as a mechanism for saying “I will process no more than n further streams”. If it were, it would be totally acceptable to open all connections with the preamble, followed immediately by GOAWAY(last_stream_id=100). This is not the intended use of GOAWAY.

Certainly my Python implementation would reject your client’s traffic, and in this regard I believe it is conformant.

Cory