RE: What error code when concurrent stream limit is exceeded

From 5.4.1:
> An endpoint can end a connection at any time. In particular, an endpoint MAY choose to treat a stream error as a connection error. Endpoints SHOULD send a GOAWAY frame when ending a connection, providing that circumstances permit it.

Saying that something is a stream error contains the implication that it could be a connection error for certain implementations.  An implementation is free to consider anything that triggers a RST_STREAM for possible upgrade to a session termination based on whatever heuristics it wants to use.  And there's not a guarantee that you'll see a GOAWAY before the connection closes in any case, particularly if the server has decided you're malicious or deranged.

For this situation, my personal opinion is that an implementation might choose to go either way.  As Roberto has pointed out, after sending SETTINGS and before receiving the ACK, the client just doesn't know better.  Kill the stream (by the time they see the RST, they'll understand why) if you want, but probably don't P-E them.  After the ACK, it's up to the implementer whether they want to be strict or just take it as input to their DoS-prevention schemes.

-----Original Message-----
From: phluid61@gmail.com [mailto:phluid61@gmail.com] On Behalf Of Matthew Kerwin
Sent: Monday, November 24, 2014 1:56 PM
To: brad@danga.com
Cc: Roberto Peon; Martin Thomson; HTTP Working Group
Subject: Re: What error code when concurrent stream limit is exceeded

So, back on track...

On 24/11/2014, Brad Fitzpatrick <brad@danga.com> wrote:
> If the peer has ACKed as many SETTINGS as you've sent, and then 
> proceeds to violate the latest SETTINGS, it's obvious then that said 
> peer just can't count (and it wasn't a network latency race). If so, 
> what else can't they follow the directions of? I'm at least in favor 
> of hanging up on them in that case.
>

Are you saying you want it to be a GOAWAY if you're confident the client should know better?

As I read the PRs, the question is about what code to put in a RST_STREAM, and as far as I'm aware there's no reasonable way to upgrade RST_STREAM to GOAWAY, and it's pretty rude (or pathological) to FIN without warning or reason. Isn't it counter to interop to send an error signal that isn't prescribed by the spec?

We *could* add a bunch more words to get to the Connection Error/Stream Error place, but I don't know if it's worth the extra convolution. Maybe it is, if the words are good ones.

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

Received on Monday, 24 November 2014 23:12:39 UTC