Re: New I-D: Retry-Scope header field

Mark Nottingham <> Tue, 21 April 2020 07:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 016A83A0414 for <>; Tue, 21 Apr 2020 00:25:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.85
X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=VANnnhuv; dkim=pass (2048-bit key) header.b=VGecwAyY
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NI3HddJTkWnZ for <>; Tue, 21 Apr 2020 00:25:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5449A3A040C for <>; Tue, 21 Apr 2020 00:25:16 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1jQnEi-0002b4-NA for; Tue, 21 Apr 2020 07:22:28 +0000
Resent-Date: Tue, 21 Apr 2020 07:22:28 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jQnEh-0002aE-R1 for; Tue, 21 Apr 2020 07:22:27 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1jQnEf-0007LX-Ae for; Tue, 21 Apr 2020 07:22:27 +0000
Received: from compute4.internal (compute4.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 504A65C01D5; Tue, 21 Apr 2020 03:22:12 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute4.internal (MEProxy); Tue, 21 Apr 2020 03:22:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=C xOo+LdDqSZyvk2t+4QU/GZhzDwzbzM/+0CKbfff7u0=; b=VANnnhuvYmQ84OxcY boSOJ+SKgDdSRIgTcdJbT8HXY7l7U8tE1273HRqPZI5txY8nJCPeVy6X3aJlO/Bh aWPjyjAWcDQbOwYlHjGJUZDAMHcQPn0aFIb5o3PJazP32R6wX6DHow83w8T2bE9E Z9wHTSFqlHeWhyzy3Fed2Su7fvPNl4KqRKtr/Hs5z1aivncDh75FQVnrhSc/WKAS OLrNa0TBI4cSO4IDFZ3quQbV3CgmgdGoj9YR0c4v/QpITV2MelWn4IErTQOT6sIq tP3kBjls/xN4/sCJY2c3se1+zrdCTg9nwvUbi341SFsrQ/cokO00x6ZKy1y1+x9h zLgDw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=CxOo+LdDqSZyvk2t+4QU/GZhzDwzbzM/+0CKbfff7 u0=; b=VGecwAyYgNMqcMcr/FTH/OjoSOZZBk8VQ1Bk+dikA11YTI1XLAsuIaf7L +PpZ2OHPGm3MzKh/pDFvH3P/Sc0U1h1DnPzbwfkyYerm1KEW+3WHETI1ZQa+Pe4H GZ/q+OP7aopOMZ9lhOZoSgOgTHg2uLgU9Gkk6969c7aL2hB+JytwlPl8kIAqPXap FXDpdGppkE7l//qXUMcgg8EvDmVbEPRZAlTt64tkP/2yY80tUygm3FWJepj0d9C2 EwPcKYR7jzCK2DsqaeqeHDxHdHhWG309N1++D8orvv7RsitW0lMHZEfZii7j5Hfs ZSG7JFR5LezZeWvL9sBQTbAxO4XBQ==
X-ME-Sender: <xms:I5-eXip4-uNoX1fot35n5fsbadKsT3dt1boSsd5jEyPmiYumVuZUjA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrgeeggdduudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne goufhushhpvggtthffohhmrghinhculdegledmnecujfgurheptggguffhjgffgffkfhfv ofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnh hothesmhhnohhtrdhnvghtqeenucffohhmrghinhepghhithhhuhgsrdhiohdpghhithhh uhgsrdgtohhmpdhmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedune cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohht sehmnhhothdrnhgvth
X-ME-Proxy: <xmx:I5-eXi7qIEuUNRgVVlb2tFmCeNR78thKu54TkR7i1JuJesaSuH1HlA> <xmx:I5-eXpflFEG71I8EQiI_XDK9wENeg48VP8i5ZpBjtF7v674nn1ql0A> <xmx:I5-eXn7ZDqQ-bb_wA2aDUry-NlqOM9IMFmOg7rqPWA752rjd8ACCVQ> <xmx:JJ-eXn3-7XumzOJPzhArda0yaTiQnwa1hs1xIKzDBVpPhQZgpEqb3w>
Received: from ( []) by (Postfix) with ESMTPA id F37BD3065C5C; Tue, 21 Apr 2020 03:22:09 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Mark Nottingham <>
In-Reply-To: <>
Date: Tue, 21 Apr 2020 17:22:06 +1000
Cc: HTTP Working Group <>, Martin Thomson <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Roberto Polli <>
X-Mailer: Apple Mail (2.3608.
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-9.8
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1jQnEf-0007LX-Ae 6488ef16b9b35708b4b9f800ea5d32c5
Subject: Re: New I-D: Retry-Scope header field
Archived-At: <>
X-Mailing-List: <> archive/latest/37532
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Roberto,

My initial personal thoughts --

While Retry-After applies to the issued request, it may be useful for the server to communicate to the user agent that the conditions that lead to returning Retry-After are broader in scope than a single request.

I don't know that it makes sense to put a different scope on retries; the only thing that's able to be retried is a request that's already been made, and the only one that a response knows about is _this_ request. In particular, Retry-After is also defined to be used by 413 Payload Too Large, and that doesn't make any sense to scope beyond the current request payload.

I _think_ the semantic you're looking for is attached to the status code (in the most obvious case, 503), not the Retry-After header.

If that's the case, the first thing I wonder is whether there are other status codes that might be relevant -- i.e., whether one should just do a "scope a 503" header, or one for any potential status code. 

After a quick look, I suspect that most of the 4xx status codes don't benefit from defining a scope (at least in terms of the server's resources). In theory 401 and 407 would, but the authentication framework already defines the concept of authentication realms. 403-406 and 410 might, but I really question what the concrete use cases would be, as well as the security considerations regarding exposing that information.

Of 5xx status codes, 503 is the only one that has an obvious fit. 

Even for 503, I wonder about the use cases. I very much doubt that a browser is going to stop making requests to a server or a portion of it based upon the value of this header (although I'd be happy to be proven wrong if one of the browser folks wants to chime in). Could you speak to what you expect a consumer to do with this information?


> On 19 Feb 2020, at 9:59 pm, Roberto Polli <> wrote:
> Hi @all,
> after a discussion with Martin and Roy on the scope of Retry-After [1]
> I wrote a brief I-D to address that issue.
> -
> It's very short and it could even be integrated in httpbis-semantics.
> Have a nice day,
> R.
> [1]:

Mark Nottingham