Re: REFUSED_STREAM and CANCEL

What Will says is also right, and what he stated is the main reason it was
put in (I think mnot was the one who suggested it, actually!)

Indeed yes-- this is documented in a conversation on spdy-dev back on
11/18/09

As Will puts it:
We're being inconsistent here and should fix it :)
-=R


On Tue, Mar 26, 2013 at 12:42 PM, William Chan (陈智昌)
<willchan@chromium.org>wrote:

> REFUSED_STREAM says it was refused before any processing happened. This
> can happen due to GOAWAY races or SETTINGS max_concurrent_streams races.
> The client knows that it's safe to retry the SYN_STREAM later on (after the
> number of streams goes down below the concurrency limit) or on a new
> connection (after a GOAWAY).
>
>
> On Tue, Mar 26, 2013 at 11:16 AM, Martin Thomson <martin.thomson@gmail.com
> > wrote:
>
>> I'm just going through the HTTP/2.0 error codes and this leaped out.
>>
>> Can anyone explain the useful difference between the REFUSED_STREAM
>> and CANCEL error codes?
>>
>> All the superficial reasons carry no semantic value:
>>  - who initiated the stream
>>  - whether the stream has (or has not) started processing
>>
>> Furthermore, the implication from REFUSED_STREAM is that this is a
>> rejection, but we don't block stream use on permission.  We just send
>> data and wait for the other side to object.
>>
>> Abandonment of a stream doesn't just occur from the stream initiator
>> side (even if that is the natural place to abort from).  The
>> implication of asymmetry seems unnecessary.
>>
>> All of the use cases could be covered with a single CANCEL_STREAM code.
>>
>>
>