Re: REFUSED_STREAM and CANCEL

On 26 March 2013 13:28, Roberto Peon <grmocg@gmail.com> 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...).

Received on Tuesday, 26 March 2013 20:42:11 UTC