Re: What error code when concurrent stream limit is exceeded

Works for me too.
On Tue, Nov 25, 2014 at 11: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/
>
>