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


From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 28 Mar 2013 00:07:58 +1300
Message-ID: <5152D30E.4010805@treenet.co.nz>
To: ietf-http-wg@w3.org
On 27/03/2013 9:41 a.m., Martin Thomson wrote:
> 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...).

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.

Received on Wednesday, 27 March 2013 11:08:35 UTC

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