idnits 2.17.1 draft-pardue-quic-http-unbound-server-push-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 1, 2018) is 2125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-13 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-13 ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Pardue 3 Internet-Draft BBC Research & Development 4 Intended status: Informational July 1, 2018 5 Expires: January 2, 2019 7 Unbound Server Push (USP) for HTTP/QUIC 8 draft-pardue-quic-http-unbound-server-push-01 10 Abstract 12 This document defines an HTTP semantic extension, Unbound Server Push 13 (USP), which allows HTTP resources to be pushed without the need for 14 a prior HTTP request. HTTP/QUIC clients opt in to this feature via 15 an HTTP/QUIC setting. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 2, 2019. 34 Copyright Notice 36 Copyright (c) 2018 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 53 2. The Unbound Promise Stream Type . . . . . . . . . . . . . . . 3 54 3. The SETTINGS_ENABLE_UNBOUND_PUSH Parameter . . . . . . . . . 3 55 4. Usage of Unbound Server Push . . . . . . . . . . . . . . . . 3 56 5. 0-RTT Considerations . . . . . . . . . . . . . . . . . . . . 4 57 6. Handling Multiple Clients . . . . . . . . . . . . . . . . . . 4 58 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 59 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 60 8.1. Registration of Unbound Promise Stream Type . . . . . . . 4 61 8.2. Registration of SETTINGS_ENABLE_UNBOUND_PUSH Parameter . 5 62 9. Normative References . . . . . . . . . . . . . . . . . . . . 5 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 5 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 HTTP server push is a feature of HTTP/2 [RFC7540] and HTTP/QUIC 69 [QUIC-HTTP] that allows a server to pre-emptively send HTTP resources 70 to a client in association with a previous client-initiated request. 71 This binding to a request object aligns with paradigms familiar to 72 client and server implementations. Unbound server push, in contrast, 73 may provide benefits for use cases where holding a request object 74 open for long periods (long polling) is undesirable, or where a 75 request object does not exist (unidirectional flows). (The 76 introduction of unidirectional streams in the QUIC transport 77 [QUIC-TRANSPORT] provides a direct expression of this message 78 exchange pattern.) 80 This document defines an HTTP/QUIC protocol extension that allows a 81 server to send one or more HTTP/QUIC "PUSH_PROMISE" frame on a new 82 server-initiated unidirectional stream type: the unbound promise 83 stream Section 2. Endpoints opt in to the unbound server push 84 feature using a "SETTINGS" parameter (Section 3) in accordance with 85 Section 5.5 of [RFC7540]. This is the only behavioural change to 86 server push as described in [QUIC-HTTP]. Unbound server push 87 operates in addition to bound server push for any HTTP/QUIC 88 connection. 90 Unbound server push should be used with care. It may introduce 91 complexities for implementations, particularly intermediaries, and it 92 can pose challenges for presentation to the application above HTTP. 94 In deployments where multiple client connections are trunked by a 95 reverse proxy onto a single upstream connection, unbound server push 96 is effectively a mechanism for achieving application-level multicast 97 to all downstream clients that have enabled this feature. 99 *Authors' Note:* Unbound server push is proposed as an extension 100 to HTTP/QUIC in order to start a discussion on whether this 101 feature should be incorporated into the core HTTP/QUIC 102 specification document. 104 1.1. Notational Conventions 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 108 "OPTIONAL" in this document are to be interpreted as described in BCP 109 14 [RFC2119] [RFC8174] when, and only when, they appear in all 110 capitals, as shown here. 112 2. The Unbound Promise Stream Type 114 An unbound promise stream is indicated by a stream type of "0xTBD". 115 Data on this stream consists of one or more "PUSH_PROMISE" frames, 116 sent in accordance with [QUIC-HTTP]. Only servers can promise; if a 117 server receives a client-initiated unbound promise stream, this MUST 118 be treated as a stream error of type HTTP_WRONG_DIRECTION. 120 3. The SETTINGS_ENABLE_UNBOUND_PUSH Parameter 122 This document adds a new HTTP/QUIC "SETTINGS" Parameter to those 123 defined by Section 7.3 of [QUIC-HTTP]. 125 The new parameter is "SETTINGS_ENABLE_UNBOUND_PUSH" (type = 0xTBD). 126 This setting can be used to enable unbound server push. The value of 127 the parameter is an integer that MUST be 0 or 1. Any value other 128 than 0 or 1 MUST be treated as a connection error of type 129 "PROTOCOL_ERROR". 131 The initial value is 0, which indicates that unbound server push is 132 disabled by default. 134 4. Usage of Unbound Server Push 136 Unbound server push changes only one aspect of HTTP/QUIC server push: 137 the stream type on which an HTTP/QUIC "PUSH_PROMISE" frame can be 138 sent. It does not prevent the conventional use of bound server push; 139 both types MAY be used concurrently. The Push ID number space is 140 shared across both types. Unbound server push is subject to the 141 limits imposed by the HTTP/QUIC "MAX_PUSH_ID" frame. 143 An endpoint that receives the "SETTINGS_ENABLE_UNBOUND_PUSH" 144 parameter set to a value of 0 MUST only send an HTTP/QUIC 145 "PUSH_PROMISE" frame on an appropriate client-initiated bidirectional 146 request stream. An endpoint that has set this parameter to 0 and had 147 it acknowledged MUST treat the reception of an HTTP/QUIC 148 "PUSH_PROMISE" frame on any other stream type as a connection error 149 of type "PROTOCOL_ERROR". 151 A server that receives the "SETTINGS_ENABLE_UNBOUND_PUSH" parameter 152 set to a value of 1 MAY send an HTTP/QUIC "PUSH_PROMISE" frame on an 153 unbound promise stream. 155 A client that has sent the "SETTINGS_ENABLE_UNBOUND_PUSH" parameter 156 set to 1, and received this parameter set to a value of 1, SHOULD be 157 ready for a server to send an HTTP/QUIC "PUSH_PROMISE" frame on 158 unbound push streams at any time. 160 5. 0-RTT Considerations 162 Client 0-RTT is not affected by server push configuration. There are 163 no additional consideration to be made beyond those defined in 164 [QUIC-HTTP]. 166 6. Handling Multiple Clients 168 Unbound server push was discussed during the development of HTTP/2 169 [RFC7540]. The assessment was that servers that handle multiple 170 clients within the same stack or context (such as an HTTP 171 intermediary) may have a difficult time routing promises to the 172 correct client. The applicability of unbound server push should be 173 assessed and enabled where the risk of misdirected promises is 174 determined to be acceptable. 176 7. Security Considerations 178 There are no additional consideration beyond those presented in 179 [QUIC-HTTP]. 181 8. IANA Considerations 183 8.1. Registration of Unbound Promise Stream Type 185 This document establishes an entry for the HTTP/QUIC Stream Type 186 registry that is established by [QUIC-HTTP]. 188 Stream Type: Unbound Promise Stream 190 Code: 0xTBD 191 Specification: This document 193 Sender: Server 195 8.2. Registration of SETTINGS_ENABLE_UNBOUND_PUSH Parameter 197 This document establishes an entry for the HTTP/QUIC Settings 198 Registry that is established by [QUIC-HTTP]. 200 Name: "SETTINGS_ENABLE_UNBOUND_PUSH" 202 Code: 0xTBD 204 Specification: This document 206 9. Normative References 208 [QUIC-HTTP] 209 Bishop, M., Ed., "Hypertext Transfer Protocol (HTTP) over 210 QUIC", draft-ietf-quic-http-13 (work in progress). 212 [QUIC-TRANSPORT] 213 Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based 214 Multiplexed and Secure Transport", draft-ietf-quic- 215 transport-13 (work in progress). 217 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 218 Requirement Levels", BCP 14, RFC 2119, 219 DOI 10.17487/RFC2119, March 1997, . 222 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 223 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 224 DOI 10.17487/RFC7540, May 2015, . 227 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 228 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 229 May 2017, . 231 Appendix A. Acknowledgements 233 The author would like to thank the following for review prior to 234 publication: Richard Bradbury. 236 Author's Address 238 Lucas Pardue 239 BBC Research & Development 241 Email: lucas.pardue@bbc.co.uk