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


From: (wrong string) 陈智昌 <willchan@chromium.org>
Date: Tue, 26 Mar 2013 12:42:07 -0700
Message-ID: <CAA4WUYhU+gtsiAu_gp-aXS1vcme50FkPpCQAmJBqiikmAUAR8Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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

> 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 19:42:35 UTC

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