W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013


From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 26 Mar 2013 13:08:05 -0700
Message-ID: <CAP+FsNcREpbTHmQ4AYspTnQWSqU5fyuKDmzzkKyFjb2qf-nxuw@mail.gmail.com>
To: William Chan (陈智昌) <willchan@chromium.org>
Cc: Martin Thomson <martin.thomson@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
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

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

On Tue, Mar 26, 2013 at 12:42 PM, William Chan (陈智昌)

> 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.
Received on Tuesday, 26 March 2013 20:08:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC