Re: What error code when concurrent stream limit is exceeded

Yup, modulo the lack of knowledge on the first RT or so...
-=R

On Sun, Nov 23, 2014 at 7:56 PM, Brad Fitzpatrick <brad@danga.com> wrote:

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