Unbound Server Push (USP) for HTTP/QUIC
BBC Research & Development
lucas.pardue@bbc.co.uk
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.
HTTP server push is a feature of HTTP/2 and HTTP/QUIC
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 provides a
direct expression of this message exchange pattern.)
This document defines an HTTP/QUIC protocol extension that allows a server to
send an HTTP/QUIC PUSH_PROMISE frame on a server-initiated unidirectional
stream. Endpoints opt in to the unbound server push feature using a SETTINGS
parameter () in accordance with Section 5.5 of . This
is the only behavioural change to server push as described in .
Unbound server push operates in addition to bound server push for any HTTP/QUIC
connection.
Unbound server push should 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.
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.
This document adds a new HTTP/QUIC SETTINGS Parameter to those defined by
Section 5.2.5.
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.
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 a server-initiated
unidirectional 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 at any time during the connection.
Client 0-RTT is not affected by server push configuration. There are no
additional consideration to be made beyond those defined in .
Unbound server push was discussed during the development of HTTP/2 .
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.
There are believed to be no additional considerations beyond those presented in
.
This document establishes an entry for the HTTP/QUIC Settings Registry that is
established by .
SETTINGS_ENABLE_UNBOUND_PUSH
0xTBD
This document
Hypertext Transfer Protocol (HTTP) over QUIC
Akamai
QUIC: A UDP-Based Multiplexed and Secure Transport
Google
Mozilla
Hypertext Transfer Protocol Version 2 (HTTP/2)
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
Key words for use in RFCs to Indicate Requirement Levels
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.
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
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.
The author would like to thank the following for review prior to publication:
Richard Bradbury.