<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.3.3 -->

<!DOCTYPE rfc SYSTEM "../Tools/rfcbootstrap/rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc tocindent="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>

<rfc ipr="trust200902" docName="draft-nottingham-bikeshed-length-00" category="info">

  <front>
    <title>Advisory Content-Length for HTTP</title>

    <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
      <organization></organization>
      <address>
        <email>mnot@mnot.net</email>
        <uri>https://www.mnot.net/</uri>
      </address>
    </author>

    <date />

    <area>General</area>
    <workgroup>HTTP</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The HTTP Content-Length header field is overloaded with (at least) two duties: message delimitation in HTTP/1, and metadata about the length of an incoming request body to the software handling it.</t>

<t>This causes confusion, and sometimes problems. This document proposes a new header to untangle these semantics (at least partially).</t>



    </abstract>


    <note title="Note to Readers">


<t><spanx style="emph">RFC EDITOR: please remove this section before publication</spanx></t>

<t>The issues list for this draft can be found at <eref target="https://github.com/mnot/I-D/labels/bikeshed-length">https://github.com/mnot/I-D/labels/bikeshed-length</eref>.</t>

<t>The most recent (often, unpublished) draft is at <eref target="https://mnot.github.io/I-D/bikeshed-length/">https://mnot.github.io/I-D/bikeshed-length/</eref>.</t>

<t>Recent changes are listed at <eref target="https://github.com/mnot/I-D/commits/gh-pages/bikeshed-length">https://github.com/mnot/I-D/commits/gh-pages/bikeshed-length</eref>.</t>

<t>See also the draft’s current status in the IETF datatracker, at
<eref target="https://datatracker.ietf.org/doc/draft-nottingham-bikeshed-length/">https://datatracker.ietf.org/doc/draft-nottingham-bikeshed-length/</eref>.</t>


    </note>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The HTTP Content-Length header field (<xref target="RFC7230"/>) is overloaded with (at least) two duties: message delimitation in HTTP/1, and metadata about the length of an incoming request body to the software handling it.</t>

<t>Message delimitation is a core feature of the protocol; it allows more than one message to be sent in a given direction on a connection. It is also security-critical; if it is under attacker control, it’s possible to confuse a recipient about how requests and responses are associated in HTTP/1.1 (as “smuggling” attacks).</t>

<t>As such, it has been treated progressively more strictly in HTTP specifications. HTTP/1.1 introduced chunked transfer encoding, and forbade sending Content-Length when it is in use. From <xref target="RFC2616"/>:</t>

<t><list style='empty'>
  <t>Messages MUST NOT include both a Content-Length header field and a
   non-identity transfer-coding. If the message does include a non-
   identity transfer-coding, the Content-Length MUST be ignored.</t>

  <t>If a message is received with both a
  Transfer-Encoding header field and a Content-Length header field,
  the latter MUST be ignored.</t>
</list></t>

<t><xref target="RFC7230"/> strengthened that to:</t>

<t><list style='empty'>
  <t>A sender MUST NOT send a Content-Length header field in any message that contains a Transfer-Encoding header field.</t>

  <t>If a message is received with both a Transfer-Encoding and a Content-Length header field, the Transfer-Encoding overrides the Content-Length. Such a message might indicate an attempt to perform request smuggling (Section 9.5) or response splitting (Section 9.4) and ought to be handled as an error. A sender MUST remove the received Content-Length field prior to forwarding such a message downstream.</t>
</list></t>

<t>HTTP/2 (<xref target="RFC7540"/>) does not use Content-Length for message delimitation, but still requires it to match the number of bytes that its framing mechanism sends:</t>

<t><list style='empty'>
  <t>A request or response that includes a payload body can include a content-length header field. A request or response is also malformed if the value of a content-length header field does not equal the sum of the DATA frame payload lengths that form the body.</t>
</list></t>

<t>It further requires such malformed responses to generate a “hard” error, so that a downstream recipient that implements HTTP/1 can’t be attacked:</t>

<t><list style='empty'>
  <t>Intermediaries that process HTTP requests or responses (i.e., any intermediary not acting as a tunnel) MUST NOT forward a malformed request or response. Malformed requests or responses that are detected MUST be treated as a stream error (Section 5.4.2) of type PROTOCOL_ERROR.</t>

  <t>For malformed requests, a server MAY send an HTTP response prior to closing or resetting the stream. Clients MUST NOT accept a malformed response. Note that these requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict because being permissive can expose implementations to these vulnerabilities.</t>
</list></t>

<t>The currently proposed HTTP/3 specification <xref target="I-D.ietf-quic-http"/> has language similar to that in HTTP/2.</t>

<t>Unfortunately, this makes <spanx style="emph">other</spanx> uses of Content-Length more difficult to implement.</t>

<t>In particular, many servers will reject a request without an explicit Content-Length using 411 (Length Required), because they want to know how many bytes are being sent before deciding to devote resources to serving the request. However, depending on the protocol version(s) between the user agent and the origin server, a Content-Length header might not make it all the way, or the request might be rejected.</t>

<t>Likewise, some applications would like to use Content-Length to indicate progress of a large download, but its successful traversal cannot be relied upon.</t>

<t>While it’s questionable whether all of the requirements above regarding Content-Length are honoured by implementations uniformly, there is enough diversity in implementation (particularly on the server side and in intermediaries) to make deployment of these uses daunting.</t>

<t>Therefore, this specification proposes a new HTTP header field to carry <spanx style="emph">advisory</spanx> content length information. It is intended only for these uses, and <spanx style="emph">not</spanx> message delimitation.</t>

<section anchor="notational-conventions" title="Notational Conventions">

<t>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 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.</t>

</section>
</section>
<section anchor="the-bikeshed-length-http-header-field" title="The Bikeshed-Length HTTP Header Field">

<t>NOTE: The final name of this header field will be selected using a to-be-defined process. Warm up your paintbrushes…</t>

<t>The Bikeshed-Length HTTP header field is a HTTP Structured Field <xref target="I-D.ietf-httpbis-header-structure"/> that conveys an advisory content length for the message body:</t>

<figure><artwork type="abnf"><![CDATA[
Bikeshed-Length = sh-item
]]></artwork></figure>

<t>Its value MUST be an Integer (Section x.x of <xref target="I-D.ietf-httpbis-header-structure"/>), indicating a decimal number of octets for a potential payload body.</t>

<t>Note that it is specifically a header field; it is not allowed to occur in trailer sections, and SHOULD be ignored if encountered there.</t>

<section anchor="example" title="Example">

<t>A resource might allow requests with bodies up to a given size. If an incoming request omits both Content-Length and Bikeshed-Length, they can respond with 411 (Length Required). If either request header field is present, and the value given is not acceptable, they can respond with 413 (Payload Too Large). If Bikeshed-Length is used and deemed to be acceptable, the resource still ought to monitor the number of incoming bytes to assure that they do not exceed the anticipated value.</t>

</section>
</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>TBD</t>

</section>
<section anchor="security-considerations" title="Security Considerations">

<t>The Value of Bikeshed-Length is advisory only; software that uses it will need to monitor the actual number of octets received to assure that it is not exceeded, and take appropriate action if it is.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>





<reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author>
<date year='1997' month='March' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>



<reference  anchor="RFC7230" target='https://www.rfc-editor.org/info/rfc7230'>
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding' role='editor'><organization /></author>
<author initials='J.' surname='Reschke' fullname='J. Reschke' role='editor'><organization /></author>
<date year='2014' month='June' />
<abstract><t>The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems.  This document provides an overview of HTTP architecture and its associated terminology, defines the &quot;http&quot; and &quot;https&quot; Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.</t></abstract>
</front>
<seriesInfo name='RFC' value='7230'/>
<seriesInfo name='DOI' value='10.17487/RFC7230'/>
</reference>



<reference  anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></author>
<date year='2017' month='May' />
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>



<reference anchor="I-D.ietf-httpbis-header-structure">
<front>
<title>Structured Field Values for HTTP</title>

<author initials='M' surname='Nottingham' fullname='Mark Nottingham'>
    <organization />
</author>

<author initials='P' surname='Kamp' fullname='Poul-Henning Kamp'>
    <organization />
</author>

<date month='March' day='15' year='2020' />

<abstract><t>This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle HTTP header and trailer fields, known as "Structured Fields", or "Structured Headers".  It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-httpbis-header-structure-17' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-httpbis-header-structure-17.txt' />
</reference>




    </references>

    <references title='Informative References'>





<reference  anchor="RFC2616" target='https://www.rfc-editor.org/info/rfc2616'>
<front>
<title>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization /></author>
<author initials='J.' surname='Gettys' fullname='J. Gettys'><organization /></author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'><organization /></author>
<author initials='H.' surname='Frystyk' fullname='H. Frystyk'><organization /></author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization /></author>
<author initials='P.' surname='Leach' fullname='P. Leach'><organization /></author>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></author>
<date year='1999' month='June' />
<abstract><t>HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as &quot;HTTP/1.1&quot;, and is an update to RFC 2068.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='2616'/>
<seriesInfo name='DOI' value='10.17487/RFC2616'/>
</reference>



<reference  anchor="RFC7540" target='https://www.rfc-editor.org/info/rfc7540'>
<front>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title>
<author initials='M.' surname='Belshe' fullname='M. Belshe'><organization /></author>
<author initials='R.' surname='Peon' fullname='R. Peon'><organization /></author>
<author initials='M.' surname='Thomson' fullname='M. Thomson' role='editor'><organization /></author>
<date year='2015' month='May' />
<abstract><t>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.</t><t>This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.  HTTP's existing semantics remain unchanged.</t></abstract>
</front>
<seriesInfo name='RFC' value='7540'/>
<seriesInfo name='DOI' value='10.17487/RFC7540'/>
</reference>



<reference anchor="I-D.ietf-quic-http">
<front>
<title>Hypertext Transfer Protocol Version 3 (HTTP/3)</title>

<author initials='M' surname='Bishop' fullname='Mike Bishop'>
    <organization />
</author>

<date month='February' day='21' year='2020' />

<abstract><t>The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment.  This document describes a mapping of HTTP semantics over QUIC.  This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to HTTP/3.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-quic-http-27' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-quic-http-27.txt' />
</reference>




    </references>



  </back>

<!-- ##markdown-source:
H4sIALp4cV4AA9VZ33PbuBF+51+BOg9n34h07MvdNUp7rS92Gs84cWo7vel0
Oh6QhCTUJMACoBVdJve399sFSMmyktxr82BJJIDd/fbbX0ie51nQoVFTcVLf
a2/dSry0JigT8gtl5mEhZtaJ1zc37zJZlk7dT7PaVka22FE7OQu5sSFoM1/I
Ni/1nfILVecNb82fPs1qGbDy4+nJzdmnrMKPOURMhTYzm2W6c1MRXO/D8dOn
z58eZ9IpORV/U0Y52WRL6+7mzvbdNCpwp1Z4VE/FORR0RoX8lDTIMh+kqW9l
Yw1krZTPOj0V/wq2mgj80aaGORMB44JTM49vqzZ9CU5XeFXZtpPpS4vFeKVN
o436d5bJPiysm2YizwT+aeOn4k0h3o5m8+OIyBvp7rbfWDeXRv8qg7Zmyk9U
K3UzFS2Q+yv9KWAKv+gd9F6E0Pnp4eFyuSyGt4dZZqxrcca9ojOuXr08Pjp6
PgWEAHJ8kWV5ngtZwixYk2U3C8XIbbt0oWStnJhp1dRCe2HvlWssntViqfF+
XwbRKOnDgQhLK+o+aAWrW+W9nCtRq0a3OrBFwINFHB5NBJyANUHC5xJa2D6I
AA0iGYSdYQGWA2KgI5z6b698EKWtV/ASr/R2FpbggFjgqIZW6VCQGdCxkr1X
+LBm1nsIjuK8hUANxUTnbNmo1heCl4OkPXmSnneWdkph1HIwHQJ7A9bMG0WS
PWTDKyboyq+tF510QcumWR0UCVv4Q92+pT/B3l7xWT7LvoU/xNnp+c3l1VR0
tFfBvhaw4nAo41XFWJUKzlKi68tGVwzft9FJ2nuAIRoNoRRvvIvDC3bTPjzt
YS40+9PAjzk81ZcF4Dwkmhye56eHjSxV4w+34vCnIkppLY53qiJY9gG1Aoi9
YW1o9UGSCNGbcpiDSZi2LGbr/EMScBXPreC6OaENO8kc9XWlKeZ08IfzRd6B
XjvVv1ZKyMZHmrCa34ALvXMkE+Efek9MpLfnZzevBFGQguBOORAlZKMCGy8K
rcKsQHgegiyHX0tmbCRRoNV13agse0JpyNm6Z9/+zmDb//jxDyDLj8ffPf30
6eD/IPbe7JRL0VQRlWcK0OMTAugQBBsSrm1eYDP81dilB+schQHkIz2PdkBq
SUEH98EKKeZIYEbU2qVQsYZFGBN/F+I8EpM4gHBCpgyrvMJfBBKJm5FELECU
AGwZAruYToCPGqRzIgwSgddlw9JjIgGrKCJ0p0mTiNvCLgeEPOPqlO+s8YnV
0nvUFEnMHvEvjuA3L/Z828/nBN5eUsFT5jhBBuirBSkBdD0Mh6koRXwGIJtD
gIf9zSqCFasSfqXzhe+g4iylDGS4UahODMQ51aI3d/gEuY2fwXQFb9dQJXID
WaUEyQhxerhN0uUCKkUEIRS4FOKVs634+PEvVGt+OPrh0yfUl59E4oMXb95f
34i3lzfEqqbHyaXFOfKL7CdFJFU6Y02uqSrDi6PGedQXro5kGilvlR+lSN5L
Z3xu/4Q3b6nB2oJweo46quoi+wm2QI4cpcBySo1wQwrEaA8k3QznnyVEdxj1
JbMnOINjEZTAs0eqZBHkmBPI+XwEeqCawgZxbBn5E/bdcAAhT7+/gjjFllmt
o47Oo5iQaGOw9cum/X6Udhz0dVgYlMcbKSE6ONfv8GMhrhFIG/q0er6gDFJT
cChKcgRy2xFqolOOmqMx3Y3RKfavU5p5Xnx/gA5tDHGEWqO5BGyueXbA5tie
hMXMxVmSihulCAGNrSu2XDR2AGqN2XZvzU7qnLbckkBbpGBGwT+0s7ZLQ8yQ
LfjC4X9MtYR58/0zriUcJqhfFL27evhdFWQiyp7qp24aRgnp11MagC7oKaEB
KW/6toRNSPHlKrBbQCIUbDFzkstJq6jqa9+y+T6xdUB9E924NYYy8a+TK6p9
sRBVsUSlMK+SBc1j5hSfOX2oD61syO+UoGMmuZdNzzXqi8euEcTZsolVsW+H
2oYR5oRNVqPa8ZCECFONFpIx8BIK1qx3eODW0LJX1+qtCwsAn/PUQyQWewuw
YC+yiuaWKEBusGCjaEVMW7SdPLmk4kBofhOIqakW1uwWnpwgWkunB1eiAlXg
Riw1Y+HbABYtsS5UMeFUotcnrBgsTBoc7+TP0KNgNwfrFJUYTUzesPqR6wpM
TluvtzSICDiib0BcYt2QR4dCygokdBi5dQR/Xzwrjg/YkatOiXdXlzeXLy8v
bs+uri6vYpZ7RRHySIcJHancPYX0yT9TwjUDUol2Y/hWjfWcwVhxFdMIsyhG
rnjZaHbRCI+sKtWFLXQGSGjMSBWAJ5TEouhlgoJcYahxpFyHzgvWCjmn1I6Y
Vvc0Q7PBniynLtuaoS0Z15EpL0jAKqHb6JJpiPYj9iHAmGcvfJI9SKqt5naF
A1Z9oOlqzb/YoqSmEi/u+4ZoXWqkVTAuTSKpc4eMNJ7VkbbfPWx1qP3AhMCN
eg7jq5zaeBRJ6qIaDBo9JTSPdNZIF2VyfomHHUPYexqPwUo2aBLnqlaisRe3
lkLzVvBUCXy2MiY3YrWeQZW+4YQ4mkixbeJsiHcSEdpSYESeeJRFTqb/YW+M
ZKdiSc1lhAzjH7LslsieyfPsCL1kenIVPV4fTEYnsKeW0rBKdwatKrWrrEDM
zuTF6ClurtPIWQNVrivYVat7YhaIZntXxeRDyg9sTSqjzbRLYtEEO7rUNlrz
oM8XZDEcte8PICksubHFe2iKJnzOPbWp+ZF1eg7PRJQmn20NYkGnvEJuSmME
H7CUcCDPxqOKaXWpEt7cTV1gbltqryZ8OSBk1w3DNnxje+T5Biv4BuBxoSQ/
D83E0JnHwgFHpzpMqT8WTiqCSOmUPWd9Q40o4YGoQ2SQCawYYr4WPWIauv2y
0I2KswgbAKUkzSNov7lQkK2p3DyM9pI6CafmqTvY0prHNmvgTogqV4+isTea
skuMAOW4UipD7Qwozi4MPGw83Cf21xxHpCbXp3ToNVVpwx2mflBUDmL3cEek
6xq74luYaJRXMdxq2RtKjjEbOKZoCs6H8b91ecN590HJpqwrHSrRrUzXl7dD
iR9m3/GGbD1FjonTGhgWL1wG5eK4dAv33e5smegm6MkTSs78E86GM+5pFAHS
MbvdUYhaV2MgpEy/N4mflPHp+9XZ39+fX52d0vfr1ycXF+OXYcX168v3F6fr
b/F5hp0vL9+8OXt7GjdTBdl6hCq1Fy3Yu3x3c3759uRiL16MbN6JEV9iG8uu
65yKBTRDV4aZuoyj7c8v34mjZyLeWNB1IxJv/PHHox+f4QcNjVEY4xh/xlLS
dQoZmaaPhqKhA3gNQeszj3xlBHmdkRQE2M/DVUviM/v5dfTzK/JzlsHWsykv
nmkCne5bI6tg2ANKcP7lu4UmNgoxr6I5sXmp8lrhgDh3U9wW4heJvq3vxArh
g6wORErXQxtfFKla7VRv+w5VxsfXwfVV4EBkzQmxsYRR9Sq1z+Pe3A9rgeUw
md2rFU8UA5232ZzIOlKTmk10dr/99huShJll27r+WfhFrjES0RJqSn3qhof2
CbKoKZyrjX7pQ/GBsP19qh9MhpQZYaZS05KHxrHBwg00LkB1tPyWzNFYsNn8
A+l1uxPvIcZM0IBb8gHeL9ISbj/plin2QLZCX8FsdxJ51g33rimmUyytR28a
D+iWpKcg4Gk7shLhffZBUi7MspOxTqZiw/LWTWoagmvqpkEiaDHcZXn9q+K7
jF03b5ZuPOPwvJ3LoemWE1NQUbsVu8M0e+9sFVik0uPcQdK2udpRe0r/JTIU
50iJqPeAK7emVJ0+L/47sf8uOfHGWnFBJTIqsE1DupmjLo8E1kq10WFEv4di
1mjHoXQcudG76pC4v2bWiGuaTC3dzvVu3TavkPTiSPehUtHFgq/5dcdDAxse
E9H5ydsTcgZVNieHdP7zKb27TjeOj9/jvH8M0+UOo8cwpgz5Yn3JyvpxLdQh
ZiyjIiabhmK06ndF0nidsGXwOiqiuapOLqZqjJyMauo0j5gxzodb03SzXWIy
yP4HkeYRdRIcAAA=

-->

</rfc>

