Unbound Server Push (USP) for HTTP/QUIC
draft-pardue-quic-http-unbound-server-push-01

Abstract

This document defines an HTTP semantic extension, Unbound Server Push (USP), which allows HTTP resources to be pushed without the need for a prior HTTP request. HTTP/QUIC clients opt in to this feature via an HTTP/QUIC setting.

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 2, 2019.

Copyright Notice

Copyright (c) 2018 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. Introduction
• 1.1. Notational Conventions
• 2. The Unbound Promise Stream Type
• 3. The SETTINGS_ENABLE_UNBOUND_PUSH Parameter
• 4. Usage of Unbound Server Push
• 5. 0-RTT Considerations
• 6. Handling Multiple Clients
• 7. Security Considerations
• 8. IANA Considerations
• 8.1. Registration of Unbound Promise Stream Type
• 8.2. Registration of SETTINGS_ENABLE_UNBOUND_PUSH Parameter
• 9. Normative References
• Appendix A. Acknowledgements
• Author's Address

1. Introduction

HTTP server push is a feature of HTTP/2 [RFC7540] and HTTP/QUIC [QUIC-HTTP] that allows a server to pre-emptively send HTTP resources to a client in association with a previous client-initiated request. This binding to a request object aligns with paradigms familiar to client and server implementations. Unbound server push, in contrast, may provide benefits for use cases where holding a request object open for long periods (long polling) is undesirable, or where a request object does not exist (unidirectional flows). (The introduction of unidirectional streams in the QUIC transport [QUIC-TRANSPORT] provides a direct expression of this message exchange pattern.)

This document defines an HTTP/QUIC protocol extension that allows a server to send one or more HTTP/QUIC PUSH_PROMISE frame on a new server-initiated unidirectional stream type: the unbound promise stream Section 2. Endpoints opt in to the unbound server push feature using a SETTINGS parameter (Section 3) in accordance with Section 5.5 of [RFC7540]. This is the only behavioural change to server push as described in [QUIC-HTTP]. Unbound server push operates in addition to bound server push for any HTTP/QUIC connection.

Unbound server push should be used with care. It may introduce complexities for implementations, particularly intermediaries, and it can pose challenges for presentation to the application above HTTP.

In deployments where multiple client connections are trunked by a reverse proxy onto a single upstream connection, unbound server push is effectively a mechanism for achieving application-level multicast to all downstream clients that have enabled this feature.

• Authors’ Note: Unbound server push is proposed as an extension to HTTP/QUIC in order to start a discussion on whether this feature should be incorporated into the core HTTP/QUIC specification document.

1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. The Unbound Promise Stream Type

An unbound promise stream is indicated by a stream type of “0xTBD”. Data on this stream consists of one or more PUSH_PROMISE frames, sent in accordance with [QUIC-HTTP]. Only servers can promise; if a server receives a client-initiated unbound promise stream, this MUST be treated as a stream error of type HTTP_WRONG_DIRECTION.

3. The SETTINGS_ENABLE_UNBOUND_PUSH Parameter

This document adds a new HTTP/QUIC SETTINGS Parameter to those defined by Section 7.3 of [QUIC-HTTP].

The new parameter is SETTINGS_ENABLE_UNBOUND_PUSH (type = 0xTBD). This setting can be used to enable unbound server push. The value of the parameter is an integer that MUST be 0 or 1. Any value other than 0 or 1 MUST be treated as a connection error of type PROTOCOL_ERROR.

The initial value is 0, which indicates that unbound server push is disabled by default.

4. Usage of Unbound Server Push

Unbound server push changes only one aspect of HTTP/QUIC server push: the stream type on which an HTTP/QUIC PUSH_PROMISE frame can be sent. It does not prevent the conventional use of bound server push; both types MAY be used concurrently. The Push ID number space is shared across both types. Unbound server push is subject to the limits imposed by the HTTP/QUIC MAX_PUSH_ID frame.

An endpoint that receives the SETTINGS_ENABLE_UNBOUND_PUSH parameter set to a value of 0 MUST only send an HTTP/QUIC PUSH_PROMISE frame on an appropriate client-initiated bidirectional request stream. An endpoint that has set this parameter to 0 and had it acknowledged MUST treat the reception of an HTTP/QUIC PUSH_PROMISE frame on any other stream type as a connection error of type PROTOCOL_ERROR.

A server that receives the SETTINGS_ENABLE_UNBOUND_PUSH parameter set to a value of 1 MAY send an HTTP/QUIC PUSH_PROMISE frame on an unbound promise stream.

A client that has sent the SETTINGS_ENABLE_UNBOUND_PUSH parameter set to 1, and received this parameter set to a value of 1, SHOULD be ready for a server to send an HTTP/QUIC PUSH_PROMISE frame on unbound push streams at any time.

5. 0-RTT Considerations

Client 0-RTT is not affected by server push configuration. There are no additional consideration to be made beyond those defined in [QUIC-HTTP].

6. Handling Multiple Clients

Unbound server push was discussed during the development of HTTP/2 [RFC7540]. The assessment was that servers that handle multiple clients within the same stack or context (such as an HTTP intermediary) may have a difficult time routing promises to the correct client. The applicability of unbound server push should be assessed and enabled where the risk of misdirected promises is determined to be acceptable.

7. Security Considerations

There are no additional consideration beyond those presented in [QUIC-HTTP].

8. IANA Considerations

8.1. Registration of Unbound Promise Stream Type

This document establishes an entry for the HTTP/QUIC Stream Type registry that is established by [QUIC-HTTP].

Stream Type:

Unbound Promise Stream

Code:

0xTBD

Specification:

This document

Sender:

Server

8.2. Registration of SETTINGS_ENABLE_UNBOUND_PUSH Parameter

This document establishes an entry for the HTTP/QUIC Settings Registry that is established by [QUIC-HTTP].

Name:

SETTINGS_ENABLE_UNBOUND_PUSH

Code:

0xTBD

Specification:

This document

9. Normative References

Appendix A. Acknowledgements

The author would like to thank the following for review prior to publication: Richard Bradbury.

Author's Address