idnits 2.17.1 draft-ruellan-http-accept-push-policy-00.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 16, 2015) is 3114 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (Obsoleted by RFC 9110) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Httpbis H. Ruellan 3 Internet-Draft Y. Fablet 4 Intended status: Experimental R. Bellessort 5 Expires: April 18, 2016 F. Denoual 6 F. Maze 7 Canon CRF 8 October 16, 2015 10 Accept-Push-Policy Header Field 11 draft-ruellan-http-accept-push-policy-00 13 Abstract 15 The "Accept-Push-Policy" and "Push-Policy" header fields enable a 16 client and a server to negotiate the behaviour of the server 17 regarding the usage of push on a per-request basis. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 18, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Push Control Use Cases . . . . . . . . . . . . . . . . . . . 3 56 2.1. Adapting Push Behaviour . . . . . . . . . . . . . . . . . 3 57 2.2. Load Balancer . . . . . . . . . . . . . . . . . . . . . . 4 58 2.3. DASH Fast Start . . . . . . . . . . . . . . . . . . . . . 4 59 2.4. Fast Page Load . . . . . . . . . . . . . . . . . . . . . 5 60 2.5. Use Cases Requirements . . . . . . . . . . . . . . . . . 5 61 3. Push Policy . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.1. The Accept-Push-Policy Header Field . . . . . . . . . . . 6 63 3.2. Push-Policy Header Field . . . . . . . . . . . . . . . . 6 64 3.3. Push Policy Values . . . . . . . . . . . . . . . . . . . 7 65 3.3.1. None Push Policy . . . . . . . . . . . . . . . . . . 7 66 3.3.2. Head Push Policy . . . . . . . . . . . . . . . . . . 7 67 3.3.3. Default Push Policy . . . . . . . . . . . . . . . . . 8 68 3.3.4. Fast-Load Push Policy . . . . . . . . . . . . . . . . 8 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 71 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 6.1. Normative References . . . . . . . . . . . . . . . . . . 9 73 6.2. Informative References . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 HTTP/2 [RFC7540], the new version of the HTTP protocol, not only 79 provides significant improvements compared to HTTP/1.1 (see [RFC7230] 80 and [RFC7231]), but also provides several new features. Among these 81 is Server Push, which enables a server to send responses to a client 82 without having received the corresponding requests. 84 The range of possibilities offered by Server Push is a new domain 85 wide open for experimentation. A first usage was foreseen early in 86 the addition of this feature into HTTP/2, which is to replace the 87 inlining of sub-resources inside a main resource, by pushing these 88 sub-resources in response to the request for the main resource. As 89 described in [HighPerformance], with HTTP/1.1 a web designer may want 90 to optimize the page load time by packing a whole web page into a 91 single HTTP response. This can be achieved by inlining the CSS, 92 JavaScript, and images inside the HTML document. By removing the 93 need for the client to send requests for these sub-resources, this 94 inlining technique can reduce the page load time by roughly a RTT. 95 With HTTP/2, the same results can be obtained by pushing the sub- 96 resources instead of inlining them. Using push has the advantage of 97 keeping each sub-resource independent. 99 HTTP/2 provides a few ways of controlling Server Push from the client 100 side. First, the SETTINGS parameter "SETTINGS_ENABLE_PUSH" allows a 101 client to globally enable or disable push on a HTTP/2 connection. In 102 addition, HTTP/2 Flow Control can be used to limit the bandwidth used 103 by pushed resources. 105 These options provide only a coarse control of the usage of Server 106 Push from the client side. In some cases, a more fine-grained 107 control would be useful. This document describes several use cases 108 where controlling Server Push would be useful for the client. It 109 then proposes new header fields for realizing this control. 111 1.1. Terminology 113 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 114 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 115 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 116 [RFC2119] and indicate requirement levels for compliant 117 implementations. 119 This document uses the Augmented BNF defined in [RFC5234]. 121 2. Push Control Use Cases 123 2.1. Adapting Push Behaviour 125 A browser may want to ask the server to adapt its behaviour for 126 pushing resources depending on the user's actions. For example, 127 after navigating through a site for some time, the browser may have 128 many sub-resources in its cache and may prefer that the server 129 doesn't push sub-resources anymore to prevent wasting bandwidth. 130 This could be further optimized with the browser asking the server to 131 push only response metadata (i.e., the responses pushed by the server 132 correspond to requests made with the HEAD method instead of requests 133 made with the GET method). By receiving in advance the list of sub- 134 resources corresponding to a specific request, the browser would be 135 able to fetch early on any missing sub-resource. 137 As another example, when a user opens many pages on the same site, 138 the browser may want to receive pushed sub-resources only for the 139 foreground tab and not for any background tab. This results in a 140 better optimization of the page load time for the tab that is visible 141 to the user. 143 2.2. Load Balancer 145 A second use case is a load balancer serving both HTTP/1.1 and HTTP/2 146 clients, and using HTTP/2 to connect to the backend servers, as 147 described in [LoadBalancer]. 149 The load balancer uses the same HTTP/2 connection towards a backend 150 server to forward the requests received from several clients. When 151 the client is a HTTP/1.1 client, the load balancer doesn't want the 152 backend server to push any resource in response to the client's 153 request. On the contrary, when the client is a HTTP/2 client, the 154 load balancer would like the backend server to push sub-resources 155 associated to the client's request. 157 The load balancer would like to be able to enable or disable push on 158 a per-request basis. This would enable it to optimize the server 159 behaviour depending on the client's capacity. 161 2.3. DASH Fast Start 163 Controlling the server behaviour regarding push may also be useful 164 for specific applications. As an example, DASH [DASH] is a 165 technology for streaming media content over HTTP. The media content 166 is split into small file-based segments that can be retrieved through 167 HTTP requests. Potentially, the media content is made available with 168 different quality levels. A media presentation description (MPD) 169 describes the organization of the media. 171 To render a media, a DASH client needs to first download the MPD, 172 process it, and then request the necessary media segments. When 173 requesting a MPD to play the associated media content, it would be 174 useful for a DASH client to be able to ask the server to push some 175 initial content (for example, the initialization segments, and 176 possibly the first content segments). 178 However, there are also cases when it is not useful for the DASH 179 client to receive in advance this initial content. For example, in a 180 video program guide, the DASH client may want to download several 181 MPDs corresponding to different media content, but doesn't want to 182 receive the initial content for all of these. Therefore, it is 183 useful for the DASH client to be able to specify in a request for a 184 MPD whether it wants the server to push some initial content. 186 In addition, when the DASH client asks the server to push some 187 initial content, it could be useful for it to have some feedback from 188 the server. This feedback would indicate whether the server is 189 intending to push this initial content. The client could adapt its 190 behaviour depending on this indication. For example, the client 191 could start rendering the media sooner if it knows that the server is 192 pushing the initial content. 194 2.4. Fast Page Load 196 The previous use case can be expanded to the more generic use case of 197 downloading quickly a web page. As described in 198 [Breaking1000msBarrier], it is important for the user perception to 199 keep the perceived latency of loading a web page under 1000 ms. This 200 can be difficult when using a mobile connection with a high latency. 201 Part of the solution proposed in [Breaking1000msBarrier] for HTTP/1.1 202 is to inline all the sub-resources necessary for achieving a first 203 rendering of the web page. With HTTP/2, the inlining of these sub- 204 resources can be replaced by having the server push them. 206 Therefore, a client detecting that it is using a high-latency network 207 could improve the user perceived latency by asking the server to push 208 all the sub-resources necessary for a first display of a web page. 210 2.5. Use Cases Requirements 212 The analysis of these use cases enables to build a list of 213 requirements for defining a fine-grained control over the usage of 214 push by a server. 216 o The client can ask the server not to push any resource in response 217 to a request. 219 o The client can ask the server to only push response metadata. 221 o The client can ask the server to use an application-defined 222 behaviour regarding push. 224 o The server can indicate to the client its behaviour regarding push 225 when processing a request. 227 3. Push Policy 229 A _push policy_ defines the server behaviour regarding push when 230 processing a request. Different push policies can be used when 231 processing different requests. 233 This section defines new header fields enabling a client and a server 234 to negotiate the push policy used by the server to process a given 235 request. 237 The new "Accept-Push-Policy" header field enables a client to express 238 its expectations regarding the server's push policy for processing a 239 request. 241 The "Push-Policy" header field enables a server to state the push 242 policy used when processing a request. 244 3.1. The Accept-Push-Policy Header Field 246 A client can express the desired push policy for a request by sending 247 an "Accept-Push-Policy" header field in the request. 249 Accept-Push-Policy = token ; a push policy name 251 The header field value contains the push policy that the client 252 expects the server to use when processing the request. 254 Possibly, the "Accept-Push-Policy" header field could be extended to 255 support carrying multiple policies, as a comma-separated list of 256 tokens. The server could choose its preferred policy among those 257 proposed by the client. 259 3.2. Push-Policy Header Field 261 A server can indicate to a client the push policy it used when 262 processing a request by sending a "Push-Policy" header field in the 263 corresponding response. 265 Push-Policy = token ; a push policy name 267 The server MUST follow the indicated push policy when processing the 268 client request associated to the response. 270 The "Push-Policy" header field can be used as an acknowledgement from 271 the server after receiving a request containing the "Accept-Push- 272 Policy" header field. 274 If the "Accept-Push-Policy" header field can contain a list of push 275 policy names, the "Push-Policy" header field can be used to express 276 which push policy was selected by the server. 278 The server can also choose a push policy not corresponding to the 279 client's expectation as expressed in the "Accept-Push-Policy" header, 280 and specify the selected push policy in the "Push-Policy" header 281 field. 283 3.3. Push Policy Values 285 This section defines some generic push policies. Other push policies 286 can be standardized for either a generic usage, or for an 287 application-specific usage. In addition, private push policies can 288 be used by a web application. 290 TBD: select the form of private push policies (URN, "X-" values...). 292 3.3.1. None Push Policy 294 The "None" push policy value indicates that no resource is pushed 295 when processing a request. 297 For example, a browser sending a request for a background tab could 298 ask the server not to push any resources in response to this request 299 by sending an "Accept-Push-Policy" header with the "None" value. 300 This would result in the following HTTP/2 header block: 302 :method = GET 303 :scheme = https 304 :path = /index.html 305 host = example.org 306 accept = text/html 307 accept-push-policy = none 309 3.3.2. Head Push Policy 311 The "Head" push policy value indicates that only response metadata 312 are pushed (the server is pushing responses corresponding to requests 313 made with the HEAD method). 315 For example, a browser may already have many resources from a web 316 site in its cache. It could ask the server to push only response 317 metadata. This would allow the browser to know early on the 318 resources useful for rendering a web page (i.e., before receiving and 319 parsing the HTML document), without taking the risk of wasting 320 bandwidth with resources already in its cache. In this example, the 321 browser's request would contain the following HTTP/2 header block: 323 :method = GET 324 :scheme = https 325 :path = /index.html 326 host = example.org 327 accept = text/html 328 accept-push-policy = head 330 3.3.3. Default Push Policy 332 The "Default" push policy value indicates that the server is using 333 its default behaviour for pushing resources when processing a 334 request. 336 For example, a server not fulfilling a client's expectation regarding 337 the push policy could indicate this with the "Default" push policy. 338 It would send the following HTTP/2 header block in its response: 340 :status 200 341 push-policy = default 343 3.3.4. Fast-Load Push Policy 345 The "Fast-Load" push policy value indicates that the sub-resources 346 necessary for a first rendering of a main resource are pushed 347 alongside the response containing this main resource. 349 A server using the "Fast-Load" push policy while processing a request 350 can push sub-resources not necessary for a first rendering, but 351 SHOULD prioritize sub-resources necessary for this first rendering. 353 For example, a client detecting that it is using a high-latency 354 network can try to improve the user perceived latency by asking the 355 server to push the sub-resources necessary for a first rendering of a 356 main page by including an "Accept-Push-Policy" header with the "Fast- 357 Load" value. This would result in the following HTTP/2 header block: 359 :method = GET 360 :scheme = https 361 :path = /index.html 362 host = example.org 363 accept = text/html 364 accept-push-policy = fast-load 366 4. IANA Considerations 368 TBD 370 5. Security Considerations 372 TBD 374 6. References 376 6.1. Normative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 380 RFC2119, March 1997, 381 . 383 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 384 Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/ 385 RFC5234, January 2008, 386 . 388 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 389 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 390 10.17487/RFC7540, May 2015, 391 . 393 6.2. Informative References 395 [Breaking1000msBarrier] 396 Grigorik, I., "Breaking the 1000 ms mobile barrier", 397 November 2013. 399 [DASH] "Dynamic adaptive streaming over HTTP (DASH)", ISO/IEC: 400 23009-1:2014 , 2014. 402 [HighPerformance] 403 Grigorik, I., "High Performance Browser Networking", 404 September 2013. 406 [LoadBalancer] 407 Douglas, S., "PUSH_PROMISE and load balancers", September 408 2014, . 411 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 412 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 413 7230, DOI 10.17487/RFC7230, June 2014, 414 . 416 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 417 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 418 10.17487/RFC7231, June 2014, 419 . 421 Authors' Addresses 423 Herve Ruellan 424 Canon CRF 426 Email: herve.ruellan@crf.canon.fr 428 Youenn Fablet 429 Canon CRF 431 Email: youenn.fablet@crf.canon.fr 433 Romain Bellessort 434 Canon CRF 436 Email: romain.bellessort@crf.canon.fr 438 Franck Denoual 439 Canon CRF 441 Email: franck.denoual@crf.canon.fr 443 Frederic Maze 444 Canon CRF 446 Email: frederic.maze@crf.canon.fr