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

Re: REFUSED_STREAM and CANCEL

From: Roberto Peon <grmocg@gmail.com>
Date: Tue, 26 Mar 2013 12:40:55 -0700
Message-ID: <CAP+FsNcYmX7rpfxjJzmTj65kyaGLP45xk1-V+rwPAooZxZmqKw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
REFUSED_STREAM is current for the receiver of a pushed stream to indicate
that it is refusing the stream for a protocol semantics violation, as
opposed to cancelling it (ostensibly because it already has it).
In the case of Chome, this can happen when the server erroneously pushes a
resource and doesn't say the associated (request) stream.


It exists just so that the error code give some idea of what went wrong ,
instead of having to rely upon text in the error which is supposed to be
opaque and implementation dependent.

-=R


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 19:41:22 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 19:41:29 GMT