RE: What error code when concurrent stream limit is exceeded

Works for me.

-----Original Message-----
From: Mark Nottingham [mailto:mnot@mnot.net] 
Sent: Tuesday, November 25, 2014 11:48 PM
To: Matthew Kerwin
Cc: Mike Bishop; brad@danga.com; Roberto Peon; Martin Thomson; HTTP Working Group
Subject: Re: What error code when concurrent stream limit is exceeded

This is <https://github.com/http2/http2-spec/issues/649>.

From my reading, it seems like we're leaning towards this resolution: <https://github.com/http2/http2-spec/pull/652>

Anyone have a problem with that?

Cheers,


> On 25 Nov 2014, at 10:39 am, Matthew Kerwin <matthew@kerwin.net.au> wrote:
> 
> On 25 November 2014 at 09:12, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 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.
> ​​
> 
> Thanks, that's the reference I was missing. It kind of changes my worldview a bit, I'll let it soak in for a while.
>  
> ​​​​
> ​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.
> 
> 
> 
> -- 
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/


--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 26 November 2014 18:14:35 UTC