Re: What error code when concurrent stream limit is exceeded

IMHO, we achieve the best interop in the end/long-term by being as strict
as possible about such things, however in this case (as already noted in
the spec):

  Limits in SETTINGS parameters cannot be reduced instantaneously,
   which leaves an endpoint exposed to behavior from a peer that could
   exceed the new limits.  In particular, immediately after establishing
   a connection, limits set by a server are not known to clients and
   could be exceeded without being an obvious protocol violation.


Thus, it is impossible to be absolutely strict here without forcing
undesirable client pessimism on the first RT or so.
It would be nice to say/remind that an implementation may wish to treat
exceeding the concurrent stream limit differently when the remote endpoint
may be unaware of the settings, e.g. before they've been ack'd (especially
so just after connecting).
-=R

On Sun, Nov 23, 2014 at 3:08 PM, Matthew Kerwin <matthew@kerwin.net.au>
wrote:

> On 24 November 2014 at 07:26, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>
>> PROTOCOL_ERROR:
>> https://github.com/http2/http2-spec/pull/651
>>
>> PROTOCOL_ERROR or REFUSED_STREAM:
>> https://github.com/http2/http2-spec/pull/652
>>
>> There's two views on this: the zero tolerance extreme who would
>> probably also choose to treat the stream error as a connection error;
>> the permissive one who don't like to punish errors more than is
>> necessary.  The full range of views is accommodated by the second PR,
>> so I prefer that marginally.  It still lets implementations fail as
>> hard as possible.
>>
>>
> I don't follow your discussion; isn't a stream error of type
> PROTOCOL_ERROR still just a stream error? I don't think it's cool to treat
> RST_STREAM(PROTOCOL_ERROR) the same as GOAWAY(PROTOCOL_ERROR).
>
> That said, I prefer #652. It allows implementations to say: "things are
> cool, but I didn't read those HEADERS" vs. "stop breaking the protocol you
> jerk." Depending on how egregious you consider a peer ignoring/exceeding
> the stream limit. (Is that what you were saying?)
>
>
>
> --
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/
>