idnits 2.17.1 draft-lnageleisen-http-chunked-progress-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 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 184 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC2616]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 95: '... The client SHOULD send the Chunk-Ex...' RFC 2119 keyword, line 97: '... header, the server SHOULD include the...' RFC 2119 keyword, line 100: '... MAY include the progress chunk exte...' RFC 2119 keyword, line 105: '...1.1 applications MUST be able to recei...' RFC 2119 keyword, line 106: '...sfer-coding, and MUST ignore chunk-ext...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 8, 2014) is 3669 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC2616' on line 11 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Nageleisen 2 Internet-Draft April 8, 2014 3 Expires: October 10, 2014 5 Chunked Progress extension to HTTP 6 draft-lnageleisen-http-chunked-progress-00 8 Abstract 10 This document describes Chunked Progress, an extension to 11 Transfer-Encoding: Chunked as defined in RFC2616 [RFC2616]. Chunked 12 Progress introduces a backwards-compatible, RFC2616 compliant method 13 to notify the client of transfer advancement in situations where the 14 server has knowledge of progress but cannot know the resource size 15 ahead of time. 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 April 1st, 2014. 34 Copyright Notice 36 Copyright (c) 2013 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 1. Overview 51 User agents have been displaying progress as feedback to the user for 52 some time already. As the nature of applications using HTTP as 53 evolved to an increaingly dynamic nature, having the User Agent 54 estimate progress based of bytes received is getting less useful, as 55 data has to be generated a priori as a whole before being sent over 56 the wire together with Content-Size, or Content-Size has to be 57 omitted altogether, even when the server could actually estimate 58 progress on the fly. In fact, Content-Size is used as a proxy for 59 actual progress towards completion. 61 While informing the client of the requested resource content size is 62 useful, it is useless when the exact resource size in bytes is not 63 known ahead of time. Nonetheless, the server may have knowledge of 64 the progress expressable as a unitless number towards completion. 66 It is important to distinguish the two notions of progress and 67 completion. Completion is handled by having received Content-Size 68 bytes, or with chunked content encoding without a Content-Size 69 header, when a zero-length chunk is received. Content-size is a 70 measure of completion, from which progress can be derived in 71 increasingly limited cases. 73 Even then, it can be an awkward proxy: imagine a scenario where a 74 known number of files of various sizes will have their SHA1 value 75 computed and sent over the wire. The content size is known beforehand 76 by a simple operation, yet progress is best measured by the number of 77 bytes read, not the number of bytes sent. 79 Thankfully, Transfer-Encoding: chunked amounts to a form of 80 multiplexing, where metadata can be sent interleaved with data on the 81 same channel. By providing complementary information establishing 82 progress towards completion, this extension aims to reduce latency 83 and resource usage while increasing feedback in a backwards 84 compatible way. Real world typical scenarios unable to generate 85 progress even though it can be known on the server side include: 87 - gzipping files on the fly 88 - generating data from result rows of a database request 89 - generating data by walking a tree of files 91 2. Progress Chunk Extension 93 2.1. Request Header 95 The client SHOULD send the Chunk-Extensions: progress header in its 96 request if it supports the feature. If the client sent the 97 Chunk-Extensions: progress header, the server SHOULD include the 98 progress chunk extension in the response chunks, compliant with 99 either basic or extended mode of operation. Otherwise, the server 100 MAY include the progress chunk extension, but MUST comply with the 101 basic mode of operation. 103 2.2 Basic mode of operation 105 Since all HTTP/1.1 applications MUST be able to receive and decode 106 the "chunked" transfer-coding, and MUST ignore chunk-extension 107 extensions they do not understand, the server MAY reliably include 108 the extension in chunks regardless of actual client-side support. 110 The chunk extension name MUST be the string "progress", while the 111 chunk extension value MUST be a short "floating point" number 112 comprised between 0 and 1, representing absolute progress towards 113 completion. The special, negative value "-1" SHOULD be used when 114 server progress tracking has been lost or compromised, and means 115 progress status is "undefined". 117 chunk-ext-name = "progress" 118 chunk-ext-val = "-1" 119 | ( "0" [ "." 0*3DIGIT ] ) 120 | ( "1" [ "." 0*3("0") ] ) 122 The progress chunk extension MAY be omitted. If no progress chunk 123 extension is present, the client MUST assume the current progress 124 chunk extension value to be equal to the previous progress chunk 125 extension value. If no previous chunk extension has been encountered 126 yet, the chunk extension value MUST be assumed to be "undefined". 128 The client MUST NOT assume the progress value to be monotonically 129 increasing, as the server MAY send any value it deems significant, 130 including "undefined". Nonetheless, the client MAY implement logic 131 presenting this information as monotonically increasing. 133 The client MUST NOT assume the value 1 to mean completion, due to 134 possible rounding errors and insufficient precision. 136 If the client did not send the appropriate Request Header, the server 137 MUST NOT send zero-length chunks unless all data has been sent, this 138 to ensure backwards compatibility. To comply with Transfer-Encoding: 139 chunked, the client, having not sent the request header, MUST accept 140 a zero-length chunk as an end of data, whether or not this chunk has 141 progress extension. 143 2.3 Enhanced mode of operation 145 If the client sent the appropriate Request Header, the server MAY 146 send zero-length chunks with progress information. In such a case, 147 the client MUST NOT assume that all data has been sent as is the case 148 with naked transfer encoding chunked, and MUST wait for a zero-length 149 chunk without a progress extension to assume completion. Indeed in 150 most cases, the server MAY skip sending the last progress chunk and 151 end the data stream with this last zero-length bare chunk instead of 152 sending two consecutive zero-length chunks. Nonetheless, the server 153 MAY, out of courtesy, send both, one notifying progress having 154 reached 1 and one marking completion of chunked data transfer. 156 3. Notes 158 The mechanism by which this extension sends additional metadata via 159 chunked extensions, even when there is no actual data to be sent, 160 effectively implements a much more general multiplexing extension, 161 which other chunked extensions may use. This area needs particular 162 scrutiny, as it alters the Transfer-Encoding: chunked mode of 163 operation. Mabye this should best be extracted in a newly defined 164 Transfer-Encoding, entirely distinct from chunked. 166 Suggestions of improvements are welcome to increase compatibility 167 with proxies, especially in the enhanced mode of operation. 169 It is regrettable that much state handling has to be done in order to 170 implement those modes of operations, but it is necessary to extend 171 current functionality all the while keeping backwards compatibility. 173 Clients and servers may restrict themselves to implement only basic 174 mode of operation, greatly simplifying the required work but limiting 175 potential functionality in the most dynamic cases. 177 Author's Addresses 179 Loic Nageleisen 181 Email: loic.nageleisen@gmail.com