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


From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 26 Mar 2013 13:41:43 -0700
Message-ID: <CABkgnnWYzB9XixZkGD9F-=sGaWoX6C3Wu0zoVe9K2bJWcBpf0Q@mail.gmail.com>
To: Roberto Peon <grmocg@gmail.com>
Cc: William Chan (ι™ˆζ™Ίζ˜Œ) <willchan@chromium.org>, HTTP Working Group <ietf-http-wg@w3.org>
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

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