Re: New Version Notification for draft-nottingham-httpbis-retry-01.txt

Tom Bergan <> Sat, 04 February 2017 19:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51F1C129C49 for <>; Sat, 4 Feb 2017 11:28:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.521
X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v2RPjjgMYe2b for <>; Sat, 4 Feb 2017 11:28:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A291129C48 for <>; Sat, 4 Feb 2017 11:28:36 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ca5xb-0005Vf-L5 for; Sat, 04 Feb 2017 19:25:23 +0000
Resent-Date: Sat, 04 Feb 2017 19:25:23 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ca5xW-0005Ub-PZ for; Sat, 04 Feb 2017 19:25:18 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <>) id 1ca5xQ-0001Dj-L8 for; Sat, 04 Feb 2017 19:25:13 +0000
Received: by with SMTP id b65so77574543wmf.0 for <>; Sat, 04 Feb 2017 11:24:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IUklpDY1AyDUagCM6E6WC3j9wSJmQ/XT03NZigiKqAA=; b=ixzYjwJl9FgJmYDRrUt9agxuKnReldGealDP8knTaH8S9QO1FqIdB0+JzUkuxrErGk tMzdhHwkGVVT92nBl10tqOFylgf6JnWNJXo/CXQ3IMgmk0TlQ3zM5XH0tHBWbkz9b+lp Y/OkeA5NXAPLQHZ1uMxyzX/FC27COZYD1jwc0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IUklpDY1AyDUagCM6E6WC3j9wSJmQ/XT03NZigiKqAA=; b=uTMGd3/31AZEWKe7HBoB1Fh2DU73ThQbgw9GGr/OC+bfDd/CjRgiyKxE+4dsyRBm81 xM6UOd4P2DpC38qd/Luf52ycvP+Xx9wN1yRlJ/+YMhXjmjxDdQ4rrxTBSQzoJvdmWtfa tFZPsX+qsZh320S8PIjAUI27373jpAeAMln+UVnn6mEwXdT04wb0phwm4ES9Bq+dMkbf MnlWg20Dw+TOEQp1fLtty9gCHSR/NcfDX8fLMg1eD/TImXfRy8M3/pp2YQCNbI3k31hu YkolrFVvkeWCFp9QLB1s6L71/qtugzGWjgXyBSQulGNDL2jlgmuRNDFiApsjWA8ymNVu cUgg==
X-Gm-Message-State: AMke39m/hvCzYuWEr0oezFF9fW6vtJoyHQL6OOBX77Y8o7zziBzSRHmG47yJqAWu0GilRaYQ
X-Received: by with SMTP id 5mr2631405wmy.1.1486236285809; Sat, 04 Feb 2017 11:24:45 -0800 (PST)
Received: from ( []) by with ESMTPSA id b8sm51365341wrb.17.2017. for <> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Feb 2017 11:24:44 -0800 (PST)
Received: by with SMTP id c85so77461310wmi.1 for <>; Sat, 04 Feb 2017 11:24:44 -0800 (PST)
X-Received: by with SMTP id b84mr2649569wmh.0.1486236284345; Sat, 04 Feb 2017 11:24:44 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 4 Feb 2017 11:24:43 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Tom Bergan <>
Date: Sat, 04 Feb 2017 11:24:43 -0800
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: "Roy T. Fielding" <>
Cc: Mark Nottingham <>, HTTP Working Group <>
Content-Type: multipart/alternative; boundary="001a114b1700c84f940547b959da"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ca5xQ-0001Dj-L8 7c429b13fd787b47e80ae1a095ec74e7
Subject: Re: New Version Notification for draft-nottingham-httpbis-retry-01.txt
Archived-At: <>
X-Mailing-List: <> archive/latest/33442
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Fri, Feb 3, 2017 at 10:03 PM, Roy T. Fielding <> wrote:

> > On Feb 1, 2017, at 12:41 PM, Tom Bergan <> wrote:
> >
> > > Applications sometimes want requests to be retried by
> > > infrastructure, but can't easily express them in a non-idempotent
> > > request (such as GET).
> >
> > nit: did you mean "in an idempotent request (such as GET)"?
> >
> > > A client SHOULD NOT automatically retry a failed automatic retry.
> >
> > Why does RFC 7230 say this? I am aware of HTTP clients that completely
> ignore this suggestion, and I can't offhand think of a reason why this is a
> good rule-of-thumb to follow.
> This is only referring to retries due to a dropped connection. The reason
> is because a
> second connection drop is (in almost all cases) due to the request itself,
> as opposed to
> something transient on the network path.  [BTW, this doesn't refer to
> requests yet to be
> sent in a request queue or pipeline -- just the retried request in flight
> for which no response
> is received prior to FIN/RST (or equivalent).]

There seem to be many underlying assumptions. I'm glad that Mark is making
things more explicit. For example, "a second connection drop is (in almost
all cases) due to the request itself" likely does not hold in flaky
cellular networks, such as getting on/off a subway. This is why Chrome will
automatically retry a failed page load when it detects a change in network
connectivity. Also think of the "parking lot problem" where you transition
between WiFi in the office and cellular in the parking lot.

I'm not sure your claim is strictly true even assuming good network
connectivity. A data point: I help run a very large proxy service. When we
experimented with automatic retries, we saw a ~40% success rate on the
first retry, ~20% on the second retry, and ~5% on the third retry. We only
retried GETs and HEADs where the connection was dropped before we received
a single byte of response. That ~20% success rate is arguably high enough
to make a second retry worthwhile (depending on your POV).

That said, I'm not trying to convince you that HTTP clients should send
multiple retries. Rather, I'm surprised that the HTTP spec takes a position
on this question in the first place. Retry logic seems like a fundamentally
application-specific property, beyond really basic things like "requests
with idempotent methods must be safe to retry."

There might be a good reason to go ahead and retry with an exponential
> back-off,
> but I don't know what that would be in general.

It is common to use exponential backoff with RPC-over-HTTP (one example
Speaking of RPC-over-HTTP, in Section 2.1 of Mark's document, perhaps we
could generalize "User Retries" to "Application Retries"? As written,
Section 2.1 is kind of specific to browsers and it's not clear how
non-browser applications fit in. RPC could be one such application. Also
think of programs like daemons that make HTTP requests (often
RPC-over-HTTP) without any direct prompting from a user.