Re: What error code when concurrent stream limit is exceeded

Marking editor-ready.


> On 26 Nov 2014, at 6:47 pm, Mark Nottingham <mnot@mnot.net> wrote:
> 
> 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/
> 
> 

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

Received on Saturday, 29 November 2014 08:11:17 UTC