idnits 2.17.00 (12 Aug 2021) /tmp/idnits5978/draft-nottingham-bikeshed-length-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([2], [3], [4], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 18, 2020) is 787 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 266 -- Looks like a reference, but probably isn't: '2' on line 268 -- Looks like a reference, but probably isn't: '3' on line 270 -- Looks like a reference, but probably isn't: '4' on line 272 == Outdated reference: draft-ietf-httpbis-header-structure has been published as RFC 8941 == Outdated reference: A later version (-34) exists of draft-ietf-quic-http-27 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HTTP M. Nottingham 3 Internet-Draft March 18, 2020 4 Intended status: Informational 5 Expires: September 19, 2020 7 Advisory Content-Length for HTTP 8 draft-nottingham-bikeshed-length-00 10 Abstract 12 The HTTP Content-Length header field is overloaded with (at least) 13 two duties: message delimitation in HTTP/1, and metadata about the 14 length of an incoming request body to the software handling it. 16 This causes confusion, and sometimes problems. This document 17 proposes a new header to untangle these semantics (at least 18 partially). 20 Note to Readers 22 _RFC EDITOR: please remove this section before publication_ 24 The issues list for this draft can be found at 25 https://github.com/mnot/I-D/labels/bikeshed-length [1]. 27 The most recent (often, unpublished) draft is at 28 https://mnot.github.io/I-D/bikeshed-length/ [2]. 30 Recent changes are listed at https://github.com/mnot/I-D/commits/gh- 31 pages/bikeshed-length [3]. 33 See also the draft's current status in the IETF datatracker, at 34 https://datatracker.ietf.org/doc/draft-nottingham-bikeshed-length/ 35 [4]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on September 19, 2020. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 72 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 73 2. The Bikeshed-Length HTTP Header Field . . . . . . . . . . . . 4 74 2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 5.1. Normative References . . . . . . . . . . . . . . . . . . 5 79 5.2. Informative References . . . . . . . . . . . . . . . . . 6 80 5.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 83 1. Introduction 85 The HTTP Content-Length header field ([RFC7230]) is overloaded with 86 (at least) two duties: message delimitation in HTTP/1, and metadata 87 about the length of an incoming request body to the software handling 88 it. 90 Message delimitation is a core feature of the protocol; it allows 91 more than one message to be sent in a given direction on a 92 connection. It is also security-critical; if it is under attacker 93 control, it's possible to confuse a recipient about how requests and 94 responses are associated in HTTP/1.1 (as "smuggling" attacks). 96 As such, it has been treated progressively more strictly in HTTP 97 specifications. HTTP/1.1 introduced chunked transfer encoding, and 98 forbade sending Content-Length when it is in use. From [RFC2616]: 100 Messages MUST NOT include both a Content-Length header field and a 101 non-identity transfer-coding. If the message does include a non- 102 identity transfer-coding, the Content-Length MUST be ignored. 104 If a message is received with both a Transfer-Encoding header 105 field and a Content-Length header field, the latter MUST be 106 ignored. 108 [RFC7230] strengthened that to: 110 A sender MUST NOT send a Content-Length header field in any 111 message that contains a Transfer-Encoding header field. 113 If a message is received with both a Transfer-Encoding and a 114 Content-Length header field, the Transfer-Encoding overrides the 115 Content-Length. Such a message might indicate an attempt to 116 perform request smuggling (Section 9.5) or response splitting 117 (Section 9.4) and ought to be handled as an error. A sender MUST 118 remove the received Content-Length field prior to forwarding such 119 a message downstream. 121 HTTP/2 ([RFC7540]) does not use Content-Length for message 122 delimitation, but still requires it to match the number of bytes that 123 its framing mechanism sends: 125 A request or response that includes a payload body can include a 126 content-length header field. A request or response is also 127 malformed if the value of a content-length header field does not 128 equal the sum of the DATA frame payload lengths that form the 129 body. 131 It further requires such malformed responses to generate a "hard" 132 error, so that a downstream recipient that implements HTTP/1 can't be 133 attacked: 135 Intermediaries that process HTTP requests or responses (i.e., any 136 intermediary not acting as a tunnel) MUST NOT forward a malformed 137 request or response. Malformed requests or responses that are 138 detected MUST be treated as a stream error (Section 5.4.2) of type 139 PROTOCOL_ERROR. 141 For malformed requests, a server MAY send an HTTP response prior 142 to closing or resetting the stream. Clients MUST NOT accept a 143 malformed response. Note that these requirements are intended to 144 protect against several types of common attacks against HTTP; they 145 are deliberately strict because being permissive can expose 146 implementations to these vulnerabilities. 148 The currently proposed HTTP/3 specification [I-D.ietf-quic-http] has 149 language similar to that in HTTP/2. 151 Unfortunately, this makes _other_ uses of Content-Length more 152 difficult to implement. 154 In particular, many servers will reject a request without an explicit 155 Content-Length using 411 (Length Required), because they want to know 156 how many bytes are being sent before deciding to devote resources to 157 serving the request. However, depending on the protocol version(s) 158 between the user agent and the origin server, a Content-Length header 159 might not make it all the way, or the request might be rejected. 161 Likewise, some applications would like to use Content-Length to 162 indicate progress of a large download, but its successful traversal 163 cannot be relied upon. 165 While it's questionable whether all of the requirements above 166 regarding Content-Length are honoured by implementations uniformly, 167 there is enough diversity in implementation (particularly on the 168 server side and in intermediaries) to make deployment of these uses 169 daunting. 171 Therefore, this specification proposes a new HTTP header field to 172 carry _advisory_ content length information. It is intended only for 173 these uses, and _not_ message delimitation. 175 1.1. Notational Conventions 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in BCP 180 14 [RFC2119] [RFC8174] when, and only when, they appear in all 181 capitals, as shown here. 183 2. The Bikeshed-Length HTTP Header Field 185 NOTE: The final name of this header field will be selected using a 186 to-be-defined process. Warm up your paintbrushes... 188 The Bikeshed-Length HTTP header field is a HTTP Structured Field 189 [I-D.ietf-httpbis-header-structure] that conveys an advisory content 190 length for the message body: 192 Bikeshed-Length = sh-item 194 Its value MUST be an Integer (Section x.x of 195 [I-D.ietf-httpbis-header-structure]), indicating a decimal number of 196 octets for a potential payload body. 198 Note that it is specifically a header field; it is not allowed to 199 occur in trailer sections, and SHOULD be ignored if encountered 200 there. 202 2.1. Example 204 A resource might allow requests with bodies up to a given size. If 205 an incoming request omits both Content-Length and Bikeshed-Length, 206 they can respond with 411 (Length Required). If either request 207 header field is present, and the value given is not acceptable, they 208 can respond with 413 (Payload Too Large). If Bikeshed-Length is used 209 and deemed to be acceptable, the resource still ought to monitor the 210 number of incoming bytes to assure that they do not exceed the 211 anticipated value. 213 3. IANA Considerations 215 TBD 217 4. Security Considerations 219 The Value of Bikeshed-Length is advisory only; software that uses it 220 will need to monitor the actual number of octets received to assure 221 that it is not exceeded, and take appropriate action if it is. 223 5. References 225 5.1. Normative References 227 [I-D.ietf-httpbis-header-structure] 228 Nottingham, M. and P. Kamp, "Structured Field Values for 229 HTTP", draft-ietf-httpbis-header-structure-17 (work in 230 progress), March 2020. 232 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 233 Requirement Levels", BCP 14, RFC 2119, 234 DOI 10.17487/RFC2119, March 1997, 235 . 237 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 238 Protocol (HTTP/1.1): Message Syntax and Routing", 239 RFC 7230, DOI 10.17487/RFC7230, June 2014, 240 . 242 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 243 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 244 May 2017, . 246 5.2. Informative References 248 [I-D.ietf-quic-http] 249 Bishop, M., "Hypertext Transfer Protocol Version 3 250 (HTTP/3)", draft-ietf-quic-http-27 (work in progress), 251 February 2020. 253 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 254 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 255 Transfer Protocol -- HTTP/1.1", RFC 2616, 256 DOI 10.17487/RFC2616, June 1999, 257 . 259 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 260 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 261 DOI 10.17487/RFC7540, May 2015, 262 . 264 5.3. URIs 266 [1] https://github.com/mnot/I-D/labels/bikeshed-length 268 [2] https://mnot.github.io/I-D/bikeshed-length/ 270 [3] https://github.com/mnot/I-D/commits/gh-pages/bikeshed-length 272 [4] https://datatracker.ietf.org/doc/draft-nottingham-bikeshed- 273 length/ 275 Author's Address 277 Mark Nottingham 279 Email: mnot@mnot.net 280 URI: https://www.mnot.net/