Team Digitale, Italian Government

robipolli@gmail.com

General Internet-Draft This document defines the Retry-Scope header field for HTTP thus allowing a server to communicate the scope of the returned Retry-After header field. Note to Readers RFC EDITOR: please remove this section before publication Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org), which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/. The source code and issues list for this draft can be found at https://github.com/ioggstream/draft-polli-Retry-Scope.

Introduction The Retry-After header defined in Section 7.1.3 of allows a server to indicate how long the user agent ought to wait before making a follow-up request. 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. This proposal allows a server to convey that scope in the Retry-Scope response header field, and ask the client to temporarily refrain from making other requests to the same resource, or even to all resources on the same server.

Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. These words may also appear in this document in lower case as plain English words, absent their normative meanings. This document uses the Augmented BNF defined in and updated by along with the "#rule" extension defined in Section 7 of and the URI-reference rule defined in Section 2.7 of . The terms "intermediaries" and "target URI" are to be interpreted as described in .

Header Specifications The following header is defined

Retry-Scope The Retry-Scope response header field indicates that the conditions that lead to returning Retry-After are broader in scope than a single request. Two examples of Retry-Scope: A user agent receiving the Retry-Scope header field in conjunction with a Retry-After header field ought to wait before making further request to the resource identified by the Retry-Scope field value. This header MUST NOT be repeated; if a user agent receives multiple Retry-Scope header fields, then it SHOULD ignore them. Intermediaries aware of the Retry-Scope semantics (eg. reverse proxies) MAY modify the Retry-Scope in order to help the user agent to correctly identify the scope and ensure that the field value matches the target URI, like they would have done for the Location header field defined in Section 7.1.2 of .

Security Considerations

Role of intermediaries An intermediary, by chance or purpose, might alter the scope of the Retry-Scope thus causing the user agent to refrain contacting other server resource. When the server originating the Retry-Scope is behind one or more intermediaries it is possible that the field value is not consistent with the target URI.

IANA Considerations

Retry-Scope Header Field Registration This section registers the Retry-Scope header field in the "Permanent Message Header Field Names" registry (). Header field name: Retry-Scope Applicable protocol: http Status: standard Author/Change controller: IETF Specification document(s): of this document

Normative References The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document extends the base definition of ABNF (Augmented Backus-Naur Form) to include a way to specify US-ASCII string literals that are matched in a case-sensitive manner. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.

Acknowledgements This specification was born from a thread created by Martin Thomson, and the subsequent discussion.

FAQ

Q: Why not using link relations?

This solution is simpler and was previously discussed here.

Change Log RFC EDITOR PLEASE DELETE THIS SECTION.