Movatterモバイル変換

HTTP                                                           B. LasseyInternet-Draft                                                    GoogleIntended status: Standards Track                               L. PardueExpires: January 26, 2020                                     Cloudflare                                                           July 25, 2019Declaring Support for HTTP/2 Prioritiesdraft-lassey-priority-setting-00Abstract   HTTP/2 provides a prioritization scheme but experience has shown that   implementation support varies.  This document defines an HTTP/2   setting that endpoints can use as an affirmative signal to indicate   their support for HTTP/2 Priorities.Status of This Memo   This Internet-Draft is submitted in full conformance with the   provisions ofBCP 78 andBCP 79.   Internet-Drafts are working documents of the Internet Engineering   Task Force (IETF).  Note that other groups may also distribute   working documents as Internet-Drafts.  The list of current Internet-   Drafts is athttps://datatracker.ietf.org/drafts/current/.   Internet-Drafts are draft documents valid for a maximum of six months   and may be updated, replaced, or obsoleted by other documents at any   time.  It is inappropriate to use Internet-Drafts as reference   material or to cite them other than as "work in progress."   This Internet-Draft will expire on January 26, 2020.Copyright Notice   Copyright (c) 2019 IETF Trust and the persons identified as the   document authors.  All rights reserved.   This document is subject toBCP 78 and the IETF Trust's Legal   Provisions Relating to IETF Documents   (https://trustee.ietf.org/license-info) in effect on the date of   publication of this document.  Please review these documents   carefully, as they describe your rights and restrictions with respect   to this document.  Code Components extracted from this document must   include Simplified BSD License text as described in Section 4.e of   the Trust Legal Provisions and are provided without warranty as   described in the Simplified BSD License.Lassey & Pardue         Expires January 26, 2020                [Page 1]

Internet-Draft   Declaring Support for HTTP/2 Priorities       July 2019Table of Contents1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .22.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .23.  The SETTINGS_ENABLE_HTTP2_PRIORITIES SETTINGS Parameter . . .24.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .34.1.  A New HTTP/2 Setting  . . . . . . . . . . . . . . . . . .35.  Normative References  . . . . . . . . . . . . . . . . . . . .3   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .31.  Introduction   The HTTP/2 specification defines a priority scheme in[RFC7540],   Section 5.3, which some implementers have opted not to fully support.   The lack of signalling about the status of the implementation has   caused several implementations to implement heuristics to detect when   the clients they are connected to do not support priorities as   defined and take steps to compensate for that.  The intent of this   draft is to provide and affirmative signalling mechanism for each   client to communicate whether or not it supports and will use the   priority scheme as defined in[RFC7540], Section 5.3.2.  Terminology   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 inBCP14 [RFC2119] [RFC8174] when, and only when, they appear in all   capitals, as shown here.3.  The SETTINGS_ENABLE_HTTP2_PRIORITIES SETTINGS Parameter   This document adds a new SETTINGS parameter to those defined by[RFC7540], Section 6.5.2.   The new parameter name is SETTINGS_ENABLE_HTTP2_PRIORITIES.  The   value of the parameter MUST be 0 or 1 to indicate not supporting or   supporting HTTP/2 priorities respectively.  If either side sends the   parameter with a value of 0, clients SHOULD NOT send priority frames   and servers SHOULD NOT make any assumptions based on the presence or   lack thereof of priority frames.  If both sides send the parameter   with a value of 1, then both parties MAY use HTTP/2 priorities as   they see fit.  A sender MUST NOT send the parameter with the value of   0 after previously sending a value of 1.  If a client or server does   not send the setting, the peer SHOULD NOT make any assumptions about   its support for HTTP/2 priorities.Lassey & Pardue         Expires January 26, 2020                [Page 2]

Internet-Draft   Declaring Support for HTTP/2 Priorities       July 20194.  IANA Considerations4.1.  A New HTTP/2 Setting   This document registers an entry in the "HTTP/2 Settings" registry   that was established bySection 11.3 of [RFC7540].   Name: SETTINGS_ENABLE_HTTP2_PRIORITIES   Code: 0xTBD   Initial Value: 1   Specification: This document5.  Normative References   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate              Requirement Levels",BCP 14,RFC 2119,              DOI 10.17487/RFC2119, March 1997,              <https://www.rfc-editor.org/info/rfc2119>.   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext              Transfer Protocol Version 2 (HTTP/2)",RFC 7540,              DOI 10.17487/RFC7540, May 2015,              <https://www.rfc-editor.org/info/rfc7540>.   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase inRFC2119 Key Words",BCP 14,RFC 8174, DOI 10.17487/RFC8174,              May 2017, <https://www.rfc-editor.org/info/rfc8174>.Authors' Addresses   Brad Lassey   Google   Email: lassey@chromium.org   Lucas Pardue   Cloudflare   Email: lucaspardue.24.7@gmail.comLassey & Pardue         Expires January 26, 2020                [Page 3]

• Info
• Contents
• Prefs