Re: REFUSED_STREAM and CANCEL

[Amos Jeffries <[e-mail]>]

On 27/03/2013 9:41 a.m., Martin Thomson 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...).

A CONNECT or Upgrade: request is requiring the TCP connection be 
converted from HTTP/1 to something else. New streams are not necessarily 
unwanted, but cannot use the connection now.

Amos