Re: What error code when concurrent stream limit is exceeded

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.



On Sun, Nov 23, 2014 at 4:15 PM, Roberto Peon <grmocg@gmail.com> wrote:

> 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/
>>
>
>