<?xml version='1.0'encoding='utf-8'?>encoding='UTF-8'?> <!DOCTYPE rfc [ <!ENTITY nbsp " "> <!ENTITY zwsp "​"> <!ENTITY nbhy "‑"> <!ENTITY wj "⁠"> ]><?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.3.3) --><rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-httpbis-zstd-window-size-03" number="9659" category="info" consensus="true" submissionType="IETF" updates="8878" tocInclude="true" sortRefs="true" symRefs="true"version="3"> <!-- xml2rfc v2v3 conversion 3.22.0 -->version="3" xml:lang="en"> <front> <titleabbrev="Zstd Window Size">Windowabbrev="Window Size for zstd">Window Sizing for Zstandard Content Encoding</title> <seriesInfoname="Internet-Draft" value="draft-ietf-httpbis-zstd-window-size-03"/>name="RFC" value="9659"/> <author initials="N." surname="Jaju" fullname="Nidhi Jaju" role="editor"> <organization>Google</organization> <address> <postal> <street>Shibuya Stream, 3 Chome-21-3 Shibuya</street> <region>Shibuya City, Tokyo</region> <code>150-0002</code> <country>Japan</country> </postal> <email>nidhijaju@google.com</email> </address> </author> <authorinitials="F."initials="W. F." surname="Handte" fullname="W. Felix P. Handte" role="editor"> <organization>Meta Platforms, Inc.</organization> <address> <postal> <street>380 W 33rd St</street> <city>New York</city> <region>NY</region> <code>10001</code><country>US</country><country>United States of America</country> </postal> <email>felixh@meta.com</email> </address> </author> <date year="2024"month="August" day="23"/> <area>Web and Internet Transport</area> <workgroup>HTTPBIS</workgroup>month="September"/> <area>WIT</area> <workgroup>httpbis</workgroup> <keyword>zstd</keyword> <keyword>zstandard</keyword> <keyword>compression</keyword> <keyword>content encoding</keyword> <keyword>content coding</keyword> <keyword>application/zstd</keyword><abstract> <?line 59?> <t>Deployments<abstract><t>Deployments of Zstandard, or "zstd", can use different window sizes to limit memory usage during compression and decompression. Some browsers and user agents limit window sizes to mitigate memory usage concerns, thereby causing interoperability issues. This document updates the window size limit inRFC8878RFC 8878 from a recommendation to a requirement in HTTP contexts.</t> </abstract><note removeInRFC="true"> <name>About This Document</name> <t> The latest revision of this draft can be found at <eref target="https://httpwg.org/http-extensions/draft-ietf-httpbis-zstd-window-size.html"/>. Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-httpbis-zstd-window-size/"/>. </t> <t> Discussion of this document takes place on the HTTP Working Group mailing list (<eref target="mailto:ietf-http-wg@w3.org"/>), which is archived at <eref target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>. </t> <t>Source for this draft and an issue tracker can be found at <eref target="https://github.com/httpwg/http-extensions/labels/zstd-window-size"/>.</t> </note></front> <middle><?line 68?><section anchor="introduction"> <name>Introduction</name> <t>Zstandard, or "zstd", specified in <xref target="RFC8878"/>, is a lossless data compression mechanism similar to gzip. When used with HTTP, the "zstd" content coding token signals to the decoder that the content is Zstandard-compressed.</t> <t>An important property of Zstandard-compressed content is its Window_Size (<xref section="3.1.1.1.2" sectionFormat="comma" target="RFC8878"/>), which describes the maximum distance for back-references and therefore how much of the content must be kept in memory during decompression.</t> <t>The minimum Window_Size is 1 KB. The maximum Window_Size is (1<<41) + 7*(1<<38) bytes, where "<<" denotes a bitwise left shift, which is 3.75 TB. Larger Window_Size values tend to improve the compressionratio,ratio but at the cost of increased memory usage.</t> <t>To protect against unreasonable memory usage, some browsers and user agents limit the maximum Window_Size they will handle. This causes failures to decode responses when the content is compressed with a larger Window_Size than the recipient allows, leading to decreased interoperability.</t> <t><xref section="3.1.1.1.2" sectionFormat="comma" target="RFC8878"/> recommends that decoders support a Window_Size of up to 8 MB, and that encoders not generate frames using a Window_Size larger than 8 MB. However, it imposes no requirements.</t> <t>This document updates <xref target="RFC8878"/> to enforce Window_Size limits on the encoder and decoder for the "zstd" HTTP content coding.</t> </section> <section anchor="conventions-and-definitions"> <name>Conventions and Definitions</name><t>The<t> The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shownhere.</t> <?line -18?>here. </t> </section> <section anchor="window-size"> <name>Window Size</name> <t>To ensure interoperability, when using the "zstd" content coding, decoders <bcp14>MUST</bcp14> support a Window_Size of up to and including 8 MB, and encoders <bcp14>MUST NOT</bcp14> generate frames requiring a Window_Size larger than 8 MB (see <xref target="zstd-iana-token"/>).</t> </section> <section anchor="security-considerations"> <name>Security Considerations</name> <t>This document introduces no new security considerations beyond those discussed in <xref target="RFC8878"/>.</t> <t>Note that decoders still need to take into account that they can receive oversized frames that do not follow the window size limit specified in this document and fail decoding when such invalid frames are received.</t> </section> <section anchor="iana-considerations"> <name>IANA Considerations</name> <section anchor="zstd-iana-token"> <name>Content Encoding</name> <t>This document updates the following entryaddedin<xref target="RFC8878"/> tothe<eref target="https://www.iana.org/assignments/http-parameters/http-parameters.xhtml#content-coding">"HTTP"HTTP Content CodingRegistry"</eref> withinRegistry" in the <ereftarget="https://www.iana.org/assignments/http-parameters/http-parameters.xhtml">"Hypertexttarget="https://www.iana.org/assignments/http-parameters">"Hypertext Transfer Protocol (HTTP)Parameters"</eref> registry:</t>Parameters" registry group</eref>:</t> <dl> <dt>Name:</dt> <dd> <t>zstd</t> </dd> <dt>Description:</dt> <dd> <t>A stream of bytes compressed using the Zstandard protocol with a Window_Size of not more than 8 MB.</t> </dd> <dt>Reference:</dt> <dd> <t>This document and <xref target="RFC8878"/></t> </dd> </dl> </section> </section> </middle> <back> <references anchor="sec-normative-references"> <name>Normative References</name><reference anchor="RFC8878"> <front> <title>Zstandard Compression and the 'application/zstd' Media Type</title> <author fullname="Y. Collet" initials="Y." surname="Collet"/> <author fullname="M. Kucherawy" initials="M." role="editor" surname="Kucherawy"/> <date month="February" year="2021"/> <abstract> <t>Zstandard, or "zstd" (pronounced "zee standard"), is a lossless data compression mechanism. This document describes the mechanism and registers a media type, content encoding, and a structured syntax suffix to be used when transporting zstd-compressed content via MIME.</t> <t>Despite use of the word "standard" as part of Zstandard, readers are advised that this document is not an Internet Standards Track specification; it is being published for informational purposes only.</t> <t>This document replaces and obsoletes RFC 8478.</t> </abstract> </front> <seriesInfo name="RFC" value="8878"/> <seriesInfo name="DOI" value="10.17487/RFC8878"/> </reference> <reference anchor="RFC2119"> <front> <title>Key words for use in RFCs to Indicate Requirement Levels</title> <author fullname="S. Bradner" initials="S." surname="Bradner"/> <date month="March" year="1997"/> <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="RFC8174"> <front> <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <author fullname="B. Leiba" initials="B." surname="Leiba"/> <date month="May" year="2017"/> <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><xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8878.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references><?line 160?><section numbered="false" anchor="acknowledgments"> <name>Acknowledgments</name> <t>Zstandard was developed byYann Collet.</t><contact fullname="Yann Collet" />.</t> <t>The authors would like to thankYann Collet, Klaus Post, Adam Rice,<contact fullname="Yann Collet" />, <contact fullname="Klaus Post" />, <contact fullname="Adam Rice" />, and members of the Web Performance Working Group in the W3C for collaborating on the window size issue and helping to formulate asolution. Also, thank you to Nick Terrell for providing feedback that went into RFC 8478 and RFC 8878.</t>solution.</t> </section> </back><!-- ##markdown-source: H4sIAAAAAAAAA61Y3XLbNha+x1OclW/irihbUTrxarJNFSdp3MaO13LGk+10 diASklCRBAuAVhRP3mWfZZ9svwNQEmk7073Y8YXFQ+D8fufDAZMkEV77XI3p RpeZWdNUf9HlgubG0j+dl2UmbUanpvSq9PSmTE2G10LOZlbdjnlJ1tqpRCq9 Whi7GZMu50aIzKSlLKA+s3LuE638PFl6X820S75gc7IOmxOHzcnxSLh6Vmjn NAxuKmw7e3P9VpR1MVN2LDIoH4vUlE6VrnZj8rZWoq5YjqeTk+cnAk6NhLRK IiI1IwRAZ3DelsrTtZWlq4z1Ym3samFNXY3p3fX15auzqVipDaTZWFBC7Fnz P2aAH1JTVFYF3+JjzIna5qQl20tkVeUaScGmo6D1VpU1giBqmcdTjPYGbnH2 f+J3kBZS58jkNmnJevHjejQwFqpJ2nQ5Jha78dFRrp13g/jyaIJX+la5o8t6 ButHbQVHbFr7ZT2LmyEJb9RneM6xuaNczlTuju6XBxtzTrQfU29rNmoIRu9r +R8KPlj6Iu+J6E6CstcqCcbH9MC4kLVfGsvlgSMEeKHiFwP6Wf5eB8G8zvMI tQudLfX+hTUMb5Vpb2wQwFtZ6i+hKGP6yZhFrsIL561SCG+61LN6I2mKZ1n0 aUSnS1Oo5OkwGW1fRtVqEXRsN5xqv+nTtVltTHgPHMD08Pvj5Pj4+GkjqkvP /fGzrGQZRCqWuWS3f4fXPy6CSwMArhPt2wG9Axy9uhfvzYDeqlx/psvOgj+J +1x5SZeoKFq9cH10STroZGF0ckw3NBqh/6c++o7wkF61pk8AaicDF5/aASPa YTfaj9N2qHN2d/ljARdClKKED/DrFp0hmDj2TyJJ0EUzOCVTL8RrVeVmU6DJ HJn5nqL6iI56jJpen1JZUu0UZXo+V5YbMiKJGEmOvKFcF9qLQhWgKiyVCyyu Lbdeq8sDeWSqJRnQFDigmTVrp6wLC2DICihgj4LaB8Yg0wt0DnXsgStS0JJj d2vHdKGZp0ylrJzpHKmm0BFuQNdL7QhMWnPc1PAd+aVqm2qM65Ku3p4GKpxb U5BEiRABdmah8OwQy/6otVVBH3YwCUXy+gwWaZJe6CxDY4gDJlBrsjrl/UI8 nnNXqVTPtcpY393dy8aJr1/7CAMWc+NcjiwS3JAdLi1UugQuXYEwCp1Lyy4u vuhqQDdLFSqZIVC/DG72Q9zR6n2+9WaF9U4vSpmHzPNSLmCmoHQpfRBsN8Gt XSjJ1iGVIfxJSbrgc0JiWRVKgmq04dZa39angYF4Gv4rnIZP7u7+0iSiT1MV EkijwTD8Pf369bBP66VOl3DSpVbPmqoW8rMu6gL4ZXup4tNYzGS6SqwKgE5V xB4WQ2KsoiVQUNTQBC/bQRa18zRTtFJVqHSEoGjA3gW3ENdsXJfBeCsODm1I v7xiJO696y4QT4YvXjwbHtJf6fl3/Ht0ckizDYC6jRFKRoPn39M19LyXdoGa tFXcyrzm+AFUFJILYM2taoLZ96RlFPdpVnva1RMhImxdpqBrrki7zzgqw0X0 SD/JhQSVoodKXmpKOcu7bQkgP9rhFDtcxCbz30gD5BtANc8JiEbzNK3LDY7Q 5uC+2kZOiKgUeKp4nHHIEaB7D54tkAX8o4se5g24DhuhK9WV5q0yz+F+n3Il uS8ae01y7rMMEvQnKN0ziItd1LSUI1dX3CZwrI161KKu2OgJnb/qN0CVzaTE 20rjCemECyDFucUh5ihQYFdRE60IEbIuHG9mrW6VBaf40KKcudK06cwFGD/G l3d3O05i5xQfM+itjkGuLg6WWInGX7E9BphFeC5uEdCeOHcsxPR5wBMzJj3O ZMTQazVHX4Xn2GYrRgrmTUe984/TazBo+E8XH8Lvqzf/+Hh29eY1/56+m7x/ v/shmhXTdx8+vn+9/7Xfefrh/PzNxeu4GVLqiETvfPKpF8vS+3B5ffbhYvK+ x9zgO2nDDM1pAncExACIHuiRTmy5KjD9q9PL//x7+IwihJ4Oh39Ddhs8DZ8/ wwMDO1ozZb5pHrlRBGZjBbaHFgAWTVJpD97GWgALfFYSsxvS+d2vnJnfxvRi llbDZz80Ag64I9zmrCMMOXsoebA5JvER0SNmdtnsyO9luuvv5FPneZv3lvDF y1yXipLhycsfAoTa1yrmML7zWPWgf/uROmL/fPNs7O+blnMnHu1c2nUulwt8 mteBP/Z9vGvhbQHE/T6OrfitXqZdL9MTpxSYJwz6WpYyCac3zsQBBw8awhGF UxeN5HSmAu3H3mmDVDeTSaSBEpOp225MOxuB440JRGTCYOjSmnlVhGFlxwsw fYGD4j7LeWb0UgHxPFPIVSgCkpSG8XY3WWzC4AmyVBhdBQ4vy3NZts1MVGoC +80NU/Q3RrjOKMVNKfZNiRD4GInOcZZD8R2f/LrEEap35rh/G1+ykNKzycXk QToPDh5c7unu4H5RvkWpkSUx4JPMsu3o12FZXvFrL9BkY0ecRitXuDlgqt/0 fnuyvU2u1+sBWw33Sel4kAuUHu+WleTAAP4Hz4PPfJE8aBCfxDAOBZ+Zuty6 sOEpDvNt/AqAMYouMRSY1OT0hP07FJc7hf83nw6FbcLEVeaCb2tCxMstX2WY R6twG2PpJNy8ZMFdGAan9vm/b+/9V5lq638zHLTPYGItjLSCp8P9CSrE1XaE DEa7dWV4tQrYXAR48mQATdJVada5yhYhA+JuHD/MqOzvvTmYW/W+tm4HtAaP Zzitc5BVhojokyxLoCDPlW9mzXinx/Bj6jwD+lcqYkaWq/bqPv2SY4SiS0x6 fZpkyNGVTlWkJExv8MGJZvDljz6XyoYrJI/OnU8q1MDhZnQaTnIkL5czw92A Jc2xHxtSuDjX4gYWzCxVXjWzFOuu+VMIcu5MXvtwM5zkzvQb3zem5oUXOl3R tbJW5blgezzS6oD+OdiE8xpZYd1wmeG7G508e34SbIYHVALZ+i+pzXbpqRMA AA== --></rfc>