Deprecation of HTTP/2 Priority Signaling Hints
draft-peon-httpbis-h2-priority-one-less-00

Abstract

This document deprecates HTTP/2 priority signaling hints.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 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 at https://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 to BCP 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.

Table of Contents

• 1. Deprecation of HTTP/2 Priority Signaling Hints
• 2. Security and Privacy Considerations
• 3. IANA Considerations
• 4. References
• 4.1. Normative References
• 4.2. Informative References
• Authors' Addresses

1. Deprecation of HTTP/2 Priority Signaling Hints

An important feature of any implementation of a protocol that provides multiplexing is the ability to prioritize the sending of information. This was an important realization in the design of HTTP/2 [HTTP2]. Prioritization is a difficult problem, so it will always be suboptimal, particularly if one endpoint operates in ignorance of the needs of its peer.

HTTP/2 introduced a complex prioritization signaling scheme that used a combination of dependencies and weights, formed into an unbalanced tree. That scheme also depends on in-order delivery, so it is unsuitable for use in protocols like HTTP/3 [HTTP3], which attempts to avoid global ordering.

Furthermore, though this scheme is rich in some ways, it has proven to be inadequate in several others. It is not well suited to major use cases like live video delivery and it cannot be used to carry hints from servers.

This prioritization scheme suffers from poor deployment and interoperability. Most server implementations do not include support for this scheme, some favoring instead bespoke schemes based on heuristics and other hints, like the content type of resources and the order in which requests arrive.

Consequently, the priority hints defined in HTTP/2 cannot be used across different HTTP versions. So either we define richer schemes that might support translation between versions, or we suffer information loss if multiple versions are in use.

Retaining the HTTP/2 priority scheme increases the complexity of the entire system without any evidence that the value it provides offsets that complexity.

This document formally deprecates the priority scheme defined in HTTP/2, acknowledging the lack of wide interoperability and its lack of suitability for new protocol versions and current use cases.

HTTP/2 servers were never obligated to use the information provided by clients in HTTP/2 PRIORITY (and HEADERS) frames. This document encourages servers to ignore those frames. Similarly, HTTP/2 clients are encouraged not to send priority information in HTTP/2.

2. Security and Privacy Considerations

HTTP/2 prioritization signaling was always optional. Processing of priority information could be used as a denial of service vector by adversaries. Ignoring priority information removes this vector.

3. IANA Considerations

This document makes no request of IANA.

4. References

4.1. Normative References

4.2. Informative References

Authors' Addresses