Re: REFUSED_STREAM and CANCEL

[Martin Thomson <[e-mail]>]

OK, I got it.  This is a new feature that the framing layer offers the
HTTP usage, namely: safely retry non-idempotent requests.

It's not explained especially well, so I've added an issue to track
the creation of a better explanation:

https://github.com/http2/http2-spec/issues/57

On 26 March 2013 13:41, Martin Thomson <[e-mail]> wrote:
> On 26 March 2013 13:28, Roberto Peon <[e-mail]> wrote:
>>> Bottom line: what do I do differently in response to a refused stream
>>> as opposed to a cancelled one?
>> You (rather, a browser) can automatically send the request again in the case
>> where a non-idempotent method such as POST was used.
>> With cancel, the browser would have to ask the client to confirm before
>> doing so.
>
> Why would the client not retry?  I would have modeled all of these as
> being equivalent to an HTTP/1.1 connection drop (albeit with a nicer
> recovery story).
>
> It might help to examine why a server would send a RST_STREAM w/
> CANCEL.  Here's what I can think of:
>  - server is overloaded, wants to send Retry-After for requests but
> not lose the connection
>  - resource disappeared or changed mid-response
>  - an upstream connection or request broke
>
> Anything else?  Because I can't see why retry is a bad idea in any of
> these cases, subject to the normal restrictions (idempotence, stream
> availability, etc...).