File: rfc9292.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2296 lines) | stat: -rw-r--r-- 93,518 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9292: Binary Representation of HTTP Messages</title>
<meta content="Martin Thomson" name="author">
<meta content="Christopher A. Wood" name="author">
<meta content="
       This document defines a binary format for representing HTTP messages. 
    " name="description">
<meta content="xml2rfc 3.14.2" name="generator">
<meta content="9292" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.14.2
    Python 3.9.13
    appdirs 1.4.4
    ConfigArgParse 1.5.3
    google-i18n-address 2.5.1
    html5lib 1.1
    intervaltree 3.1.0
    Jinja2 3.1.2
    kitchen 1.2.6
    lxml 4.9.0
    MarkupSafe 2.1.1
    pycountry 22.3.5
    PyYAML 6.0
    requests 2.28.0
    setuptools 44.1.1
    six 1.16.0
    weasyprint 56.1
-->
<link href="rfc9292.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  display: table;
  border: none;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.ulBare, li.ulBare {
  margin-left: 0em !important;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  pre.breakable {
    break-inside: auto;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr {
  break-inside: avoid;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9292" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-httpbis-binary-message-06" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9292</td>
<td class="center">Binary HTTP Messages</td>
<td class="right">August 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Thomson &amp; Wood</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9292" class="eref">9292</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-08" class="published">August 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">M. Thomson</div>
<div class="org">Mozilla</div>
</div>
<div class="author">
      <div class="author-name">C. A. Wood</div>
<div class="org">Cloudflare</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9292</h1>
<h1 id="title">Binary Representation of HTTP Messages</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines a binary format for representing HTTP messages.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9292">https://www.rfc-editor.org/info/rfc9292</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-and-definitions" class="xref">Conventions and Definitions</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-format" class="xref">Format</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-known-length-messages" class="xref">Known-Length Messages</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-indeterminate-length-messag" class="xref">Indeterminate-Length Messages</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-framing-indicator" class="xref">Framing Indicator</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-request-control-data" class="xref">Request Control Data</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-response-control-data" class="xref">Response Control Data</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5.2.1">
                    <p id="section-toc.1-1.3.2.5.2.1.1"><a href="#section-3.5.1" class="xref">3.5.1</a>.  <a href="#name-informational-status-codes" class="xref">Informational Status Codes</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6">
                <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-header-and-trailer-field-li" class="xref">Header and Trailer Field Lines</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.7">
                <p id="section-toc.1-1.3.2.7.1"><a href="#section-3.7" class="xref">3.7</a>.  <a href="#name-content" class="xref">Content</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.8">
                <p id="section-toc.1-1.3.2.8.1"><a href="#section-3.8" class="xref">3.8</a>.  <a href="#name-padding-and-truncation" class="xref">Padding and Truncation</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-invalid-messages" class="xref">Invalid Messages</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-examples" class="xref">Examples</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-request-example" class="xref">Request Example</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-response-example" class="xref">Response Example</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-notable-differences-with-ht" class="xref">Notable Differences with HTTP Protocol Messages</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-message-bhttp-media-type" class="xref">"message/bhttp" Media Type</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">This document defines a simple format for representing an HTTP message
<span>[<a href="#RFC9110" class="xref">HTTP</a>]</span>, either request or response. This allows for the encoding of HTTP
messages that can be conveyed outside an HTTP protocol. This enables the
transformation of entire messages, including the application of authenticated
encryption.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">The design of this format is informed by the framing structure of HTTP/2
<span>[<a href="#RFC9113" class="xref">HTTP/2</a>]</span> and HTTP/3 <span>[<a href="#RFC9114" class="xref">HTTP/3</a>]</span>.  Rules for constructing messages rely on the rules
defined in HTTP/2, but the format itself is distinct; see <a href="#differences" class="xref">Section 6</a>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">This format defines <code>"message/bhttp"</code>, a binary alternative to the <code>"message/http"</code>
content type defined in <span>[<a href="#RFC9112" class="xref">HTTP/1.1</a>]</span>. A binary format permits more efficient
encoding and processing of messages. A binary format also reduces exposure to
security problems related to processing of HTTP messages.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Two modes for encoding are described:<a href="#section-1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-5.1">a known-length encoding includes length prefixes for all major message
components, and<a href="#section-1-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.2">an indeterminate-length encoding enables efficient generation of messages
where lengths are not known when encoding starts.<a href="#section-1-5.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-6">This format is designed to convey the semantics of valid HTTP messages as simply
and efficiently as possible.  It is not designed to capture all of the details
of the encoding of messages from specific HTTP versions <span>[<a href="#RFC9112" class="xref">HTTP/1.1</a>]</span> <span>[<a href="#RFC9113" class="xref">HTTP/2</a>]</span>
        <span>[<a href="#RFC9114" class="xref">HTTP/3</a>]</span>.  As such, this format is unlikely to be suitable for applications that
depend on an exact recording of the encoding of messages.<a href="#section-1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="conventions-and-definitions">
<section id="section-2">
      <h2 id="name-conventions-and-definitions">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-and-definitions" class="section-name selfRef">Conventions and Definitions</a>
      </h2>
<p id="section-2-1">The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
       "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>",
       "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>",
       "<span class="bcp14">SHOULD NOT</span>",
       "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
       "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document
       are to be interpreted as described in BCP 14
       <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only
       when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">This document uses terminology from HTTP <span>[<a href="#RFC9110" class="xref">HTTP</a>]</span> and notation from QUIC
(<span><a href="https://www.rfc-editor.org/rfc/rfc9000#section-1.3" class="relref">Section 1.3</a> of [<a href="#RFC9000" class="xref">QUIC</a>]</span>).<a href="#section-2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="format">
<section id="section-3">
      <h2 id="name-format">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-format" class="section-name selfRef">Format</a>
      </h2>
<p id="section-3-1"><span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-6" class="relref">Section 6</a> of [<a href="#RFC9110" class="xref">HTTP</a>]</span> defines the general structure of HTTP messages and
composes those messages into distinct parts.  This format describes how those
parts are composed into a sequence of bytes.  At a high level, binary messages
are comprised of:<a href="#section-3-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3-2">
<li id="section-3-2.1">Framing indicator. This format uses a single integer to describe framing, which describes
whether the message is a request or response and how subsequent sections are
formatted; see <a href="#framing" class="xref">Section 3.3</a>.<a href="#section-3-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.2">For a response, zero or more informational responses.  Each informational
response consists of an informational status code and header section.<a href="#section-3-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.3">Control data. For a request, this contains the request method and target.
For a response, this contains the status code.<a href="#section-3-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.4">Header section.  This contains zero or more header fields.<a href="#section-3-2.4" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.5">Content.  This is a sequence of zero or more bytes.<a href="#section-3-2.5" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.6">Trailer section.  This contains zero or more trailer fields.<a href="#section-3-2.6" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.7">Optional padding. Any amount of zero-valued bytes.<a href="#section-3-2.7" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-3-3">All lengths and numeric values are encoded using the variable-length integer
encoding from <span><a href="https://www.rfc-editor.org/rfc/rfc9000#section-16" class="relref">Section 16</a> of [<a href="#RFC9000" class="xref">QUIC</a>]</span>.  Integer values do not need to be encoded
on the minimum number of bytes necessary.<a href="#section-3-3" class="pilcrow">¶</a></p>
<div id="known-length-messages">
<section id="section-3.1">
        <h3 id="name-known-length-messages">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-known-length-messages" class="section-name selfRef">Known-Length Messages</a>
        </h3>
<p id="section-3.1-1">A request or response that has a known length at the time of construction uses
the format shown in <a href="#format-known-length" class="xref">Figure 1</a>.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<span id="name-known-length-message"></span><div id="format-known-length">
<figure id="figure-1">
          <div class="alignLeft art-text artwork" id="section-3.1-2.1">
<pre>
Known-Length Request {
  Framing Indicator (i) = 0,
  Request Control Data (..),
  Known-Length Field Section (..),
  Known-Length Content (..),
  Known-Length Field Section (..),
  Padding (..),
}

Known-Length Response {
  Framing Indicator (i) = 1,
  Known-Length Informational Response (..) ...,
  Final Response Control Data (..),
  Known-Length Field Section (..),
  Known-Length Content (..),
  Known-Length Field Section (..),
  Padding (..),
}

Known-Length Field Section {
  Length (i),
  Field Line (..) ...,
}

Known-Length Content {
  Content Length (i),
  Content (..),
}

Known-Length Informational Response {
  Informational Response Control Data (..),
  Known-Length Field Section (..),
}
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-known-length-message" class="selfRef">Known-Length Message</a>
          </figcaption></figure>
</div>
<p id="section-3.1-3">A known-length request consists of a framing indicator (<a href="#framing" class="xref">Section 3.3</a>), request
control data (<a href="#request-control" class="xref">Section 3.4</a>), a header section with a length prefix,
binary content with a length prefix, a trailer section with a length prefix, and
padding.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">A known-length response contains the same fields, with the exception that
request control data is replaced by zero or more informational responses
(<a href="#informational" class="xref">Section 3.5.1</a>) followed by response control data (<a href="#response-control" class="xref">Section 3.5</a>).<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">For a known-length encoding, the length prefix on field sections and content is
a variable-length encoding of an integer.  This integer is the number of bytes
in the field section or content, not including the length field itself.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<p id="section-3.1-6">Fields in the header and trailer sections consist of a length-prefixed name and
length-prefixed value; see <a href="#fields" class="xref">Section 3.6</a>.<a href="#section-3.1-6" class="pilcrow">¶</a></p>
<p id="section-3.1-7">The format allows for the message to be truncated before any of the length
prefixes that precede the field sections or content; see <a href="#padding" class="xref">Section 3.8</a>.<a href="#section-3.1-7" class="pilcrow">¶</a></p>
<p id="section-3.1-8">The variable-length integer encoding means that there is a limit of 2<sup>62</sup>-1
bytes for each field section and the message content.<a href="#section-3.1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="indeterminate-length-messages">
<section id="section-3.2">
        <h3 id="name-indeterminate-length-messag">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-indeterminate-length-messag" class="section-name selfRef">Indeterminate-Length Messages</a>
        </h3>
<p id="section-3.2-1">A request or response that is constructed without encoding a known length for
each section uses the format shown in <a href="#format-indeterminate-length" class="xref">Figure 2</a>:<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<span id="name-indeterminate-length-message"></span><div id="format-indeterminate-length">
<figure id="figure-2">
          <div class="alignLeft art-text artwork" id="section-3.2-2.1">
<pre>
Indeterminate-Length Request  {
  Framing Indicator (i) = 2,
  Request Control Data (..),
  Indeterminate-Length Field Section (..),
  Indeterminate-Length Content (..),
  Indeterminate-Length Field Section (..),
  Padding (..),
}

Indeterminate-Length Response  {
  Framing Indicator (i) = 3,
  Indeterminate-Length Informational Response (..) ...,
  Final Response Control Data (..),
  Indeterminate-Length Field Section (..),
  Indeterminate-Length Content (..),
  Indeterminate-Length Field Section (..),
  Padding (..),
}

Indeterminate-Length Content {
  Indeterminate-Length Content Chunk (..) ...,
  Content Terminator (i) = 0,
}

Indeterminate-Length Content Chunk {
  Chunk Length (i) = 1..,
  Chunk (..),
}

Indeterminate-Length Field Section {
  Field Line (..) ...,
  Content Terminator (i) = 0,
}

Indeterminate-Length Informational Response {
  Informational Response Control Data (..),
  Indeterminate-Length Field Section (..),
}
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-indeterminate-length-message" class="selfRef">Indeterminate-Length Message</a>
          </figcaption></figure>
</div>
<p id="section-3.2-3">An indeterminate-length request consists of a framing indicator (<a href="#framing" class="xref">Section 3.3</a>),
request control data (<a href="#request-control" class="xref">Section 3.4</a>), a header section that is terminated
by a zero value, any number of non-zero-length chunks of binary content, a zero
value, a trailer section that is terminated by a zero value, and padding.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">An indeterminate-length response contains the same fields, with the exception
that request control data is replaced by zero or more informational responses
(<a href="#informational" class="xref">Section 3.5.1</a>) and response control data (<a href="#response-control" class="xref">Section 3.5</a>).<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<p id="section-3.2-5">The indeterminate-length encoding only uses length prefixes for content blocks.
Multiple length-prefixed portions of content can be included, each prefixed by a
non-zero Chunk Length integer describing the number of bytes in the block.  The
Chunk Length is encoded as a variable-length integer.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2-6">Each Field Line in an Indeterminate-Length Field Section starts with a Name
Length field.  An Indeterminate-Length Field Section ends with a Content
Terminator field.  The zero value of the Content Terminator distinguishes it
from the Name Length field, which cannot contain a value of 0.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
<p id="section-3.2-7">Indeterminate-length messages can be truncated in a way similar to that for
known-length
messages; see <a href="#padding" class="xref">Section 3.8</a>.<a href="#section-3.2-7" class="pilcrow">¶</a></p>
<p id="section-3.2-8">Indeterminate-length messages use the same encoding for Field Line as
known-length messages; see <a href="#fields" class="xref">Section 3.6</a>.<a href="#section-3.2-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="framing">
<section id="section-3.3">
        <h3 id="name-framing-indicator">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-framing-indicator" class="section-name selfRef">Framing Indicator</a>
        </h3>
<p id="section-3.3-1">The start of each binary message is a framing indicator that is a single integer that
describes the structure of the subsequent sections. The framing indicator can
take just four values:<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.3-2.1">A value of 0 describes a request of known length.<a href="#section-3.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.3-2.2">A value of 1 describes a response of known length.<a href="#section-3.3-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.3-2.3">A value of 2 describes a request of indeterminate length.<a href="#section-3.3-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.3-2.4">A value of 3 describes a response of indeterminate length.<a href="#section-3.3-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.3-3">Other values cause the message to be invalid; see <a href="#invalid" class="xref">Section 4</a>.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="request-control">
<section id="section-3.4">
        <h3 id="name-request-control-data">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-request-control-data" class="section-name selfRef">Request Control Data</a>
        </h3>
<p id="section-3.4-1">The control data for a request message contains the method and request target.
That information is encoded as an ordered sequence of fields: Method, Scheme,
Authority, Path. Each of these fields is prefixed with a length.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">The values of these fields follow the rules in HTTP/2 (<span><a href="https://www.rfc-editor.org/rfc/rfc9113#section-8.3.1" class="relref">Section 8.3.1</a> of [<a href="#RFC9113" class="xref">HTTP/2</a>]</span>)
that apply to the <code>":method"</code>, <code>":scheme"</code>, <code>":authority"</code>, and <code>":path"</code> pseudo-header
fields, respectively. However, where the <code>":authority"</code> pseudo-header field might
be omitted in HTTP/2, a zero-length value is encoded instead.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
<p id="section-3.4-3">The format of request control data is shown in <a href="#format-request-control-data" class="xref">Figure 3</a>.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
<span id="name-format-of-request-control-d"></span><div id="format-request-control-data">
<figure id="figure-3">
          <div class="alignLeft art-text artwork" id="section-3.4-4.1">
<pre>
Request Control Data {
  Method Length (i),
  Method (..),
  Scheme Length (i),
  Scheme (..),
  Authority Length (i),
  Authority (..),
  Path Length (i),
  Path (..),
}
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-format-of-request-control-d" class="selfRef">Format of Request Control Data</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="response-control">
<section id="section-3.5">
        <h3 id="name-response-control-data">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-response-control-data" class="section-name selfRef">Response Control Data</a>
        </h3>
<p id="section-3.5-1">The control data for a response message consists of the status code. The status
code (<span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-15" class="relref">Section 15</a> of [<a href="#RFC9110" class="xref">HTTP</a>]</span>) is encoded as a variable-length integer, not a
length-prefixed decimal string.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">The format of final response control data is shown in
<a href="#format-response-control-data" class="xref">Figure 4</a>.<a href="#section-3.5-2" class="pilcrow">¶</a></p>
<span id="name-format-of-final-response-co"></span><div id="format-response-control-data">
<figure id="figure-4">
          <div class="alignLeft art-text artwork" id="section-3.5-3.1">
<pre>
Final Response Control Data {
  Status Code (i) = 200..599,
}
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-format-of-final-response-co" class="selfRef">Format of Final Response Control Data</a>
          </figcaption></figure>
</div>
<div id="informational">
<section id="section-3.5.1">
          <h4 id="name-informational-status-codes">
<a href="#section-3.5.1" class="section-number selfRef">3.5.1. </a><a href="#name-informational-status-codes" class="section-name selfRef">Informational Status Codes</a>
          </h4>
<p id="section-3.5.1-1">Responses that include informational status codes (see <span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-15.2" class="relref">Section 15.2</a> of [<a href="#RFC9110" class="xref">HTTP</a>]</span>)
are encoded by repeating the response control data and associated header section
until a final status code is encoded; that is, a Status Code field with a value from 200 to 599 (inclusive).  The status code distinguishes
between informational and final responses.<a href="#section-3.5.1-1" class="pilcrow">¶</a></p>
<p id="section-3.5.1-2">The format of the informational response control data is shown in
<a href="#format-informational" class="xref">Figure 5</a>.<a href="#section-3.5.1-2" class="pilcrow">¶</a></p>
<span id="name-format-of-informational-res"></span><div id="format-informational">
<figure id="figure-5">
            <div class="alignLeft art-text artwork" id="section-3.5.1-3.1">
<pre>
Informational Response Control Data {
  Status Code (i) = 100..199,
}
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-format-of-informational-res" class="selfRef">Format of Informational Response Control Data</a>
            </figcaption></figure>
</div>
<p id="section-3.5.1-4">A response message can include any number of informational responses that
precede a final status code.  These convey an informational status code and a
header block.<a href="#section-3.5.1-4" class="pilcrow">¶</a></p>
<p id="section-3.5.1-5">If the response control data includes an informational status code (that is, a
value between 100 and 199 inclusive), the control data is followed by a header
section (encoded with known length or indeterminate length according to the framing
indicator) and another block of control data.  This pattern repeats until the
control data contains a final status code (200 to 599 inclusive).<a href="#section-3.5.1-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="fields">
<section id="section-3.6">
        <h3 id="name-header-and-trailer-field-li">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-header-and-trailer-field-li" class="section-name selfRef">Header and Trailer Field Lines</a>
        </h3>
<p id="section-3.6-1">Header and trailer sections consist of zero or more field lines; see <span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-5" class="relref">Section 5</a> of [<a href="#RFC9110" class="xref">HTTP</a>]</span>. The format of a field section depends on whether the message is of
known length or indeterminate length.<a href="#section-3.6-1" class="pilcrow">¶</a></p>
<p id="section-3.6-2">Each Field Line encoding includes a name and a value. Both the name and value are
length-prefixed sequences of bytes.  The Name field is a minimum of one
byte. The format of a Field Line is shown in <a href="#format-field-line" class="xref">Figure 6</a>.<a href="#section-3.6-2" class="pilcrow">¶</a></p>
<span id="name-format-of-a-field-line"></span><div id="format-field-line">
<figure id="figure-6">
          <div class="alignLeft art-text artwork" id="section-3.6-3.1">
<pre>
Field Line {
  Name Length (i) = 1..,
  Name (..),
  Value Length (i),
  Value (..),
}
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-format-of-a-field-line" class="selfRef">Format of a Field Line</a>
          </figcaption></figure>
</div>
<p id="section-3.6-4">For field names, byte values that are not permitted in an HTTP field name cause
the message to be invalid; see <span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-5.1" class="relref">Section 5.1</a> of [<a href="#RFC9110" class="xref">HTTP</a>]</span> for a definition of what
is valid and <a href="#invalid" class="xref">Section 4</a> regarding the handling of invalid messages.  A recipient <span class="bcp14">MUST</span>
treat a message that contains field values that would cause an HTTP/2 message to
be malformed according to <span><a href="https://www.rfc-editor.org/rfc/rfc9113#section-8.2.1" class="relref">Section 8.2.1</a> of [<a href="#RFC9113" class="xref">HTTP/2</a>]</span> as invalid; see <a href="#invalid" class="xref">Section 4</a>.<a href="#section-3.6-4" class="pilcrow">¶</a></p>
<p id="section-3.6-5">The same field name can be repeated over more than one field line; see <span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC9110" class="xref">HTTP</a>]</span> for the semantics of repeated field names and rules for combining
values.<a href="#section-3.6-5" class="pilcrow">¶</a></p>
<p id="section-3.6-6">Messages are invalid (<a href="#invalid" class="xref">Section 4</a>) if they contain fields named <code>":method"</code>,
<code>":scheme"</code>, <code>":authority"</code>, <code>":path"</code>, or <code>":status"</code>.  Other pseudo-fields that are
defined by protocol extensions <span class="bcp14">MAY</span> be included; pseudo-fields cannot be included
in trailers (see <span><a href="https://www.rfc-editor.org/rfc/rfc9113#section-8.1" class="relref">Section 8.1</a> of [<a href="#RFC9113" class="xref">HTTP/2</a>]</span>).  A Field Line containing pseudo-fields
<span class="bcp14">MUST</span> precede other Field Line values.  A message that contains a pseudo-field after
any other field is invalid; see <a href="#invalid" class="xref">Section 4</a>.<a href="#section-3.6-6" class="pilcrow">¶</a></p>
<p id="section-3.6-7">Fields that relate to connections (<span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-7.6.1" class="relref">Section 7.6.1</a> of [<a href="#RFC9110" class="xref">HTTP</a>]</span>) cannot be used to
produce the effect on a connection in this context.  These fields <span class="bcp14">SHOULD</span> be
removed when constructing a binary message.  However, they do not cause a
message to be invalid (<a href="#invalid" class="xref">Section 4</a>); permitting these fields allows a binary
message to capture messages that are exchanged in a protocol context.<a href="#section-3.6-7" class="pilcrow">¶</a></p>
<p id="section-3.6-8">Like HTTP/2 or HTTP/3, this format has an exception for the combination of
multiple instances of the <code>Cookie</code> field. Instances of fields with the
ASCII-encoded value of <code>"cookie"</code> are combined using a semicolon octet (0x3b)
rather than a comma; see <span><a href="https://www.rfc-editor.org/rfc/rfc9113#section-8.2.3" class="relref">Section 8.2.3</a> of [<a href="#RFC9113" class="xref">HTTP/2</a>]</span>.<a href="#section-3.6-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="content">
<section id="section-3.7">
        <h3 id="name-content">
<a href="#section-3.7" class="section-number selfRef">3.7. </a><a href="#name-content" class="section-name selfRef">Content</a>
        </h3>
<p id="section-3.7-1">The content of messages is a sequence of bytes of any length. Though a
known-length message has a limit, this limit is large enough that it is
unlikely to be a practical limitation. There is no limit to the size of content
in an indeterminate-length message.<a href="#section-3.7-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="padding">
<section id="section-3.8">
        <h3 id="name-padding-and-truncation">
<a href="#section-3.8" class="section-number selfRef">3.8. </a><a href="#name-padding-and-truncation" class="section-name selfRef">Padding and Truncation</a>
        </h3>
<p id="section-3.8-1">Messages can be padded with any number of zero-valued bytes.  Non-zero padding
bytes cause a message to be invalid (see <a href="#invalid" class="xref">Section 4</a>). Unlike other parts of a
message, a processor <span class="bcp14">MAY</span> decide not to validate the value of padding bytes.<a href="#section-3.8-1" class="pilcrow">¶</a></p>
<p id="section-3.8-2">Truncation can be used to reduce the size of messages that have no data in
trailing field sections or content.  If the trailers of a message are empty, they
<span class="bcp14">MAY</span> be omitted by the encoder in place of adding a length field equal to
zero. An encoder <span class="bcp14">MAY</span> omit empty content in the same way if the trailers are also
empty.  A message that is truncated at any other point is invalid; see
<a href="#invalid" class="xref">Section 4</a>.<a href="#section-3.8-2" class="pilcrow">¶</a></p>
<p id="section-3.8-3">Decoders <span class="bcp14">MUST</span> treat missing truncated fields as equivalent to having been sent
with the length field set to zero.<a href="#section-3.8-3" class="pilcrow">¶</a></p>
<p id="section-3.8-4">Padding is compatible with truncation of empty parts of the messages.
Zero-valued bytes will be interpreted as a zero-length part, which is semantically
equivalent to the part being absent.<a href="#section-3.8-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="invalid">
<section id="section-4">
      <h2 id="name-invalid-messages">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-invalid-messages" class="section-name selfRef">Invalid Messages</a>
      </h2>
<p id="section-4-1">This document describes a number of ways that a message can be invalid. Invalid
messages <span class="bcp14">MUST NOT</span> be processed further except to log an error and produce an
error response.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">The format is designed to allow incremental processing. Implementations need to
be aware of the possibility that an error might be detected after performing
incremental processing.<a href="#section-4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="examples">
<section id="section-5">
      <h2 id="name-examples">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-examples" class="section-name selfRef">Examples</a>
      </h2>
<p id="section-5-1">This section includes example requests and responses encoded in both
known-length and indeterminate-length forms.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="request-example">
<section id="section-5.1">
        <h3 id="name-request-example">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-request-example" class="section-name selfRef">Request Example</a>
        </h3>
<p id="section-5.1-1">The example HTTP/1.1 message in <a href="#ex-request" class="xref">Figure 7</a> shows the content in the
<code>"message/http"</code> format.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">Valid HTTP/1.1 messages require lines terminated with CRLF (the two bytes 0x0d and 0x0a). For simplicity and consistency, the content of these examples is
limited to text, which also uses CRLF for line endings.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<span id="name-sample-http-request"></span><div id="ex-request">
<figure id="figure-7">
          <div id="section-5.1-3.1">
<pre class="lang-http-message sourcecode">
GET /hello.txt HTTP/1.1
User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/0.9.7l zlib/1.2.3
Host: www.example.com
Accept-Language: en, mi
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-sample-http-request" class="selfRef">Sample HTTP Request</a>
          </figcaption></figure>
</div>
<p id="section-5.1-4">This can be expressed as a binary message (type <code>"message/bhttp"</code>) using a
known-length encoding as shown in hexadecimal in <a href="#ex-bink-request" class="xref">Figure 8</a>.
<a href="#ex-bink-request" class="xref">Figure 8</a> includes text alongside to show that most of the content is
not modified.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
<span id="name-known-length-binary-encodin"></span><div id="ex-bink-request">
<figure id="figure-8">
          <div class="alignLeft art-text artwork" id="section-5.1-5.1">
<pre>
00034745 54056874 74707300 0a2f6865  ..GET.https../he
6c6c6f2e 74787440 6c0a7573 65722d61  llo.txt@l.user-a
67656e74 34637572 6c2f372e 31362e33  gent4curl/7.16.3
206c6962 6375726c 2f372e31 362e3320   libcurl/7.16.3
4f70656e 53534c2f 302e392e 376c207a  OpenSSL/0.9.7l z
6c69622f 312e322e 3304686f 73740f77  lib/1.2.3.host.w
77772e65 78616d70 6c652e63 6f6d0f61  ww.example.com.a
63636570 742d6c61 6e677561 67650665  ccept-language.e
6e2c206d 690000                      n, mi..
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-known-length-binary-encodin" class="selfRef">Known-Length Binary Encoding of Request</a>
          </figcaption></figure>
</div>
<p id="section-5.1-6">This example shows that the Host header field is not replicated in the
<code>":authority"</code> field, as is required for ensuring that the request is reproduced
accurately; see <span><a href="https://www.rfc-editor.org/rfc/rfc9113#section-8.3.1" class="relref">Section 8.3.1</a> of [<a href="#RFC9113" class="xref">HTTP/2</a>]</span>.<a href="#section-5.1-6" class="pilcrow">¶</a></p>
<p id="section-5.1-7">The same message can be truncated with no effect on interpretation. In this
case, the last two bytes -- corresponding to content and a trailer section -- can
each be removed without altering the semantics of the message.<a href="#section-5.1-7" class="pilcrow">¶</a></p>
<p id="section-5.1-8">The same message, encoded using an indeterminate-length encoding, is shown in
<a href="#ex-bini-request" class="xref">Figure 9</a>. As the content of this message is empty, the difference in
formats is negligible.<a href="#section-5.1-8" class="pilcrow">¶</a></p>
<span id="name-indeterminate-length-binary"></span><div id="ex-bini-request">
<figure id="figure-9">
          <div class="alignLeft art-text artwork" id="section-5.1-9.1">
<pre>
02034745 54056874 74707300 0a2f6865  ..GET.https../he
6c6c6f2e 7478740a 75736572 2d616765  llo.txt.user-age
6e743463 75726c2f 372e3136 2e33206c  nt4curl/7.16.3 l
69626375 726c2f37 2e31362e 33204f70  ibcurl/7.16.3 Op
656e5353 4c2f302e 392e376c 207a6c69  enSSL/0.9.7l zli
622f312e 322e3304 686f7374 0f777777  b/1.2.3.host.www
2e657861 6d706c65 2e636f6d 0f616363  .example.com.acc
6570742d 6c616e67 75616765 06656e2c  ept-language.en,
206d6900 00000000 00000000 00000000   mi.............
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-indeterminate-length-binary" class="selfRef">Indeterminate-Length Binary Encoding of Request</a>
          </figcaption></figure>
</div>
<p id="section-5.1-10">This indeterminate-length encoding contains 10 bytes of padding.  As two additional
bytes can be truncated in the same way as the known-length example, anything up
to 12 bytes can be removed from this message without affecting its meaning.<a href="#section-5.1-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="response-example">
<section id="section-5.2">
        <h3 id="name-response-example">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-response-example" class="section-name selfRef">Response Example</a>
        </h3>
<p id="section-5.2-1">Response messages can contain interim (1xx) status codes, as the message in
<a href="#ex-response" class="xref">Figure 10</a> shows. <a href="#ex-response" class="xref">Figure 10</a> includes examples of informational
status codes 102 and 103, as defined in <span>[<a href="#RFC2518" class="xref">RFC2518</a>]</span> (now obsolete but defines status code 102) and <span>[<a href="#RFC8297" class="xref">RFC8297</a>]</span>, respectively.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<span id="name-sample-http-response"></span><div id="ex-response">
<figure id="figure-10">
          <div id="section-5.2-2.1">
<pre class="lang-http-message sourcecode">
HTTP/1.1 102 Processing
Running: "sleep 15"

HTTP/1.1 103 Early Hints
Link: &lt;/style.css&gt;; rel=preload; as=style
Link: &lt;/script.js&gt;; rel=preload; as=script

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Hello World! My content includes a trailing CRLF.
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-sample-http-response" class="selfRef">Sample HTTP Response</a>
          </figcaption></figure>
</div>
<p id="section-5.2-3">As this is a longer example, only the indeterminate-length encoding is shown in
<a href="#ex-bini-response" class="xref">Figure 11</a>. Note here that the specific text used in the reason
phrase is not retained by this encoding.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<span id="name-binary-response-including-i"></span><div id="ex-bini-response">
<figure id="figure-11">
          <div class="alignLeft art-text artwork" id="section-5.2-4.1">
<pre>
03406607 72756e6e 696e670a 22736c65  .@f.running."sle
65702031 35220040 67046c69 6e6b233c  ep 15".@g.link#&lt;
2f737479 6c652e63 73733e3b 2072656c  /style.css&gt;; rel
3d707265 6c6f6164 3b206173 3d737479  =preload; as=sty
6c65046c 696e6b24 3c2f7363 72697074  le.link$&lt;/script
2e6a733e 3b207265 6c3d7072 656c6f61  .js&gt;; rel=preloa
643b2061 733d7363 72697074 0040c804  d; as=script.@..
64617465 1d4d6f6e 2c203237 204a756c  date.Mon, 27 Jul
20323030 39203132 3a32383a 35332047   2009 12:28:53 G
4d540673 65727665 72064170 61636865  MT.server.Apache
0d6c6173 742d6d6f 64696669 65641d57  .last-modified.W
65642c20 3232204a 756c2032 30303920  ed, 22 Jul 2009
31393a31 353a3536 20474d54 04657461  19:15:56 GMT.eta
67142233 34616133 38372d64 2d313536  g."34aa387-d-156
38656230 30220d61 63636570 742d7261  8eb00".accept-ra
6e676573 05627974 65730e63 6f6e7465  nges.bytes.conte
6e742d6c 656e6774 68023531 04766172  nt-length.51.var
790f4163 63657074 2d456e63 6f64696e  y.Accept-Encodin
670c636f 6e74656e 742d7479 70650a74  g.content-type.t
6578742f 706c6169 6e003348 656c6c6f  ext/plain.3Hello
20576f72 6c642120 4d792063 6f6e7465   World! My conte
6e742069 6e636c75 64657320 61207472  nt includes a tr
61696c69 6e672043 524c462e 0d0a0000  ailing CRLF.....
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-binary-response-including-i" class="selfRef">Binary Response, including Informational Responses</a>
          </figcaption></figure>
</div>
<p id="section-5.2-5">A response that uses the chunked encoding (see <span><a href="https://www.rfc-editor.org/rfc/rfc9112#section-7.1" class="relref">Section 7.1</a> of [<a href="#RFC9112" class="xref">HTTP/1.1</a>]</span>) as
shown in <a href="#ex-chunked" class="xref">Figure 12</a> can be encoded using indeterminate-length encoding, which
minimizes buffering needed to translate into the binary format. However, chunk
boundaries do not need to be retained, and any chunk extensions cannot be
conveyed using the binary format; see <a href="#differences" class="xref">Section 6</a>.<a href="#section-5.2-5" class="pilcrow">¶</a></p>
<span id="name-chunked-encoding-example"></span><div id="ex-chunked">
<figure id="figure-12">
          <div id="section-5.2-6.1">
<pre class="lang-http-message sourcecode">
HTTP/1.1 200 OK
Transfer-Encoding: chunked

4
This
6
 conte
13;chunk-extension=foo
nt contains CRLF.

0
Trailer: text
</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-chunked-encoding-example" class="selfRef">Chunked Encoding Example</a>
          </figcaption></figure>
</div>
<p id="section-5.2-7"><a href="#ex-bink-chunked" class="xref">Figure 13</a> shows this message using the known-length encoding. Note that
the Transfer-Encoding header field is removed.<a href="#section-5.2-7" class="pilcrow">¶</a></p>
<span id="name-known-length-encoding-of-re"></span><div id="ex-bink-chunked">
<figure id="figure-13">
          <div class="alignLeft art-text artwork" id="section-5.2-8.1">
<pre>
0140c800 1d546869 7320636f 6e74656e  .@...This conten
7420636f 6e746169 6e732043 524c462e  t contains CRLF.
0d0a0d07 74726169 6c657204 74657874  ....trailer.text
</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
<a href="#name-known-length-encoding-of-re" class="selfRef">Known-Length Encoding of Response</a>
          </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<div id="differences">
<section id="section-6">
      <h2 id="name-notable-differences-with-ht">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-notable-differences-with-ht" class="section-name selfRef">Notable Differences with HTTP Protocol Messages</a>
      </h2>
<p id="section-6-1">This format is designed to carry HTTP semantics just like HTTP/1.1 <span>[<a href="#RFC9112" class="xref">HTTP/1.1</a>]</span>, HTTP/2 <span>[<a href="#RFC9113" class="xref">HTTP/2</a>]</span>, or
HTTP/3 <span>[<a href="#RFC9114" class="xref">HTTP/3</a>]</span>.  However, there are some notable
differences between this format and the format used in an interactive protocol
version.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">In particular, as a standalone representation, this format lacks the following
features of the formats used in those protocols:<a href="#section-6-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-3.1">chunk extensions (<span><a href="https://www.rfc-editor.org/rfc/rfc9112#section-7.1.1" class="relref">Section 7.1.1</a> of [<a href="#RFC9112" class="xref">HTTP/1.1</a>]</span>) and transfer encoding
(<span><a href="https://www.rfc-editor.org/rfc/rfc9112#section-6.1" class="relref">Section 6.1</a> of [<a href="#RFC9112" class="xref">HTTP/1.1</a>]</span>)<a href="#section-6-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-3.2">generic framing and extensibility capabilities<a href="#section-6-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-3.3">field blocks other than a single header and trailer field block<a href="#section-6-3.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-3.4">carrying reason phrases in responses (<span><a href="https://www.rfc-editor.org/rfc/rfc9112#section-4" class="relref">Section 4</a> of [<a href="#RFC9112" class="xref">HTTP/1.1</a>]</span>)<a href="#section-6-3.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-3.5">header compression <span>[<a href="#RFC7541" class="xref">HPACK</a>]</span> <span>[<a href="#RFC9204" class="xref">QPACK</a>]</span><a href="#section-6-3.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-3.6">response framing that depends on the corresponding request (such as HEAD)
or the value of the status code (such as 204 or 304); these responses use the
same framing as all other messages<a href="#section-6-3.6" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-6-4">Some of these features are also absent in HTTP/2 and HTTP/3.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control data
rather than using pseudo-fields.<a href="#section-6-5" class="pilcrow">¶</a></p>
<p id="section-6-6">Note that while some messages -- CONNECT or upgrade requests in particular -- can
be represented using this format, doing so serves no purpose, as these requests
are used to affect protocol behavior, which this format cannot do without
additional mechanisms.<a href="#section-6-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="media-type">
<section id="section-7">
      <h2 id="name-message-bhttp-media-type">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-message-bhttp-media-type" class="section-name selfRef">"message/bhttp" Media Type</a>
      </h2>
<p id="section-7-1">The <code>"message/bhttp"</code> media type can be used to enclose a single HTTP request or
response message, provided that it obeys the MIME restrictions for all
"message" types regarding line length and encodings.<a href="#section-7-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-7-2">
        <dt id="section-7-2.1">Type name:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.2">
          <p id="section-7-2.2.1">message<a href="#section-7-2.2.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.3">Subtype name:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.4">
          <p id="section-7-2.4.1">bhttp<a href="#section-7-2.4.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.5">Required parameters:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.6">
          <p id="section-7-2.6.1">N/A<a href="#section-7-2.6.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.7">Optional parameters:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.8">
          <p id="section-7-2.8.1">N/A<a href="#section-7-2.8.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.9">Encoding considerations:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.10">
          <p id="section-7-2.10.1">Only "8bit" or "binary" is permitted.<a href="#section-7-2.10.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.11">Security considerations:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.12">
          <p id="section-7-2.12.1">See <a href="#security" class="xref">Section 8</a>.<a href="#section-7-2.12.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.13">Interoperability considerations:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.14">
          <p id="section-7-2.14.1">N/A<a href="#section-7-2.14.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.15">Published specification:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.16">
          <p id="section-7-2.16.1">RFC 9292<a href="#section-7-2.16.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.17">Applications that use this media type:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.18">
          <p id="section-7-2.18.1">Applications seeking to convey HTTP semantics that are independent of a
specific protocol.<a href="#section-7-2.18.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.19">Fragment identifier considerations:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.20">
          <p id="section-7-2.20.1">N/A<a href="#section-7-2.20.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.21">Additional information:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.22">
          <span class="break"></span><dl class="dlCompact dlParallel" id="section-7-2.22.1">
            <dt id="section-7-2.22.1.1">Deprecated alias names for this type:</dt>
            <dd style="margin-left: 1.5em" id="section-7-2.22.1.2">N/A<a href="#section-7-2.22.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7-2.22.1.3">Magic number(s):</dt>
            <dd style="margin-left: 1.5em" id="section-7-2.22.1.4">N/A<a href="#section-7-2.22.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7-2.22.1.5">File extension(s):</dt>
            <dd style="margin-left: 1.5em" id="section-7-2.22.1.6">N/A<a href="#section-7-2.22.1.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-7-2.22.1.7">Macintosh file type code(s):</dt>
            <dd style="margin-left: 1.5em" id="section-7-2.22.1.8">N/A<a href="#section-7-2.22.1.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.23">Person &amp; email address to contact for further information:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.24">
          <p id="section-7-2.24.1">See the Authors' Addresses section.<a href="#section-7-2.24.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.25">Intended usage:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.26">
          <p id="section-7-2.26.1">COMMON<a href="#section-7-2.26.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.27">Restrictions on usage:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.28">
          <p id="section-7-2.28.1">N/A<a href="#section-7-2.28.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.29">Author:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.30">
          <p id="section-7-2.30.1">See the Authors' Addresses section.<a href="#section-7-2.30.1" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-7-2.31">Change controller:</dt>
        <dd style="margin-left: 1.5em" id="section-7-2.32">
          <p id="section-7-2.32.1">IESG<a href="#section-7-2.32.1" class="pilcrow">¶</a></p>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="security">
<section id="section-8">
      <h2 id="name-security-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-8-1">Many of the considerations that apply to HTTP message handling apply to this
format; see <span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-17" class="relref">Section 17</a> of [<a href="#RFC9110" class="xref">HTTP</a>]</span> and <span><a href="https://www.rfc-editor.org/rfc/rfc9112#section-11" class="relref">Section 11</a> of [<a href="#RFC9112" class="xref">HTTP/1.1</a>]</span> for common
issues in handling HTTP messages.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">Strict parsing of the format with no tolerance for errors can help avoid a
number of attacks. However, implementations still need to be aware of the
possibility of resource exhaustion attacks that might arise from receiving
large messages, particularly those with large numbers of fields.<a href="#section-8-2" class="pilcrow">¶</a></p>
<p id="section-8-3">Implementations need to ensure that they aren't subject to resource exhaustion
attacks from maliciously crafted messages.  Overall, the format is designed to
allow for minimal state when processing messages.  However, producing a combined
field value (<span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC9110" class="xref">HTTP</a>]</span>) for fields might require the commitment of
resources.  In particular, combining might be necessary for the <code>Cookie</code> field
when translating this format for use in other contexts, such as use in an API or
translation to HTTP/1.1 <span>[<a href="#RFC9112" class="xref">HTTP/1.1</a>]</span>, where the recipient of the field might
not expect multiple values.<a href="#section-8-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-9">
      <h2 id="name-iana-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-9-1">IANA has added the media type <code>"message/bhttp"</code> to the "Media Types" registry at
<span>&lt;<a href="https://www.iana.org/assignments/media-types">https://www.iana.org/assignments/media-types</a>&gt;</span>. See <a href="#media-type" class="xref">Section 7</a> for registration
information.<a href="#section-9-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10">
      <h2 id="name-references">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-10.1">
        <h3 id="name-normative-references">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC9110">[HTTP]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"HTTP Semantics"</span>, <span class="seriesInfo">STD 97</span>, <span class="seriesInfo">RFC 9110</span>, <span class="seriesInfo">DOI 10.17487/RFC9110</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9110">https://www.rfc-editor.org/info/rfc9110</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9113">[HTTP/2]</dt>
        <dd>
<span class="refAuthor">Thomson, M., Ed.</span> and <span class="refAuthor">C. Benfield, Ed.</span>, <span class="refTitle">"HTTP/2"</span>, <span class="seriesInfo">RFC 9113</span>, <span class="seriesInfo">DOI 10.17487/RFC9113</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9113">https://www.rfc-editor.org/info/rfc9113</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9000">[QUIC]</dt>
        <dd>
<span class="refAuthor">Iyengar, J., Ed.</span> and <span class="refAuthor">M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="seriesInfo">RFC 9000</span>, <span class="seriesInfo">DOI 10.17487/RFC9000</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9000">https://www.rfc-editor.org/info/rfc9000</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
      <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-10.2">
        <h3 id="name-informative-references">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC7541">[HPACK]</dt>
        <dd>
<span class="refAuthor">Peon, R.</span> and <span class="refAuthor">H. Ruellan</span>, <span class="refTitle">"HPACK: Header Compression for HTTP/2"</span>, <span class="seriesInfo">RFC 7541</span>, <span class="seriesInfo">DOI 10.17487/RFC7541</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7541">https://www.rfc-editor.org/info/rfc7541</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9112">[HTTP/1.1]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"HTTP/1.1"</span>, <span class="seriesInfo">STD 99</span>, <span class="seriesInfo">RFC 9112</span>, <span class="seriesInfo">DOI 10.17487/RFC9112</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9112">https://www.rfc-editor.org/info/rfc9112</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9114">[HTTP/3]</dt>
        <dd>
<span class="refAuthor">Bishop, M., Ed.</span>, <span class="refTitle">"HTTP/3"</span>, <span class="seriesInfo">RFC 9114</span>, <span class="seriesInfo">DOI 10.17487/RFC9114</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9114">https://www.rfc-editor.org/info/rfc9114</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9204">[QPACK]</dt>
        <dd>
<span class="refAuthor">Krasic, C.</span>, <span class="refAuthor">Bishop, M.</span>, and <span class="refAuthor">A. Frindell, Ed.</span>, <span class="refTitle">"QPACK: Field Compression for HTTP/3"</span>, <span class="seriesInfo">RFC 9204</span>, <span class="seriesInfo">DOI 10.17487/RFC9204</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9204">https://www.rfc-editor.org/info/rfc9204</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2518">[RFC2518]</dt>
        <dd>
<span class="refAuthor">Goland, Y.</span>, <span class="refAuthor">Whitehead, E.</span>, <span class="refAuthor">Faizi, A.</span>, <span class="refAuthor">Carter, S.</span>, and <span class="refAuthor">D. Jensen</span>, <span class="refTitle">"HTTP Extensions for Distributed Authoring -- WEBDAV"</span>, <span class="seriesInfo">RFC 2518</span>, <span class="seriesInfo">DOI 10.17487/RFC2518</span>, <time datetime="1999-02" class="refDate">February 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2518">https://www.rfc-editor.org/info/rfc2518</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8297">[RFC8297]</dt>
      <dd>
<span class="refAuthor">Oku, K.</span>, <span class="refTitle">"An HTTP Status Code for Indicating Hints"</span>, <span class="seriesInfo">RFC 8297</span>, <span class="seriesInfo">DOI 10.17487/RFC8297</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8297">https://www.rfc-editor.org/info/rfc8297</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acknowledgments">
<section id="appendix-A">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-A-1"><span class="contact-name">Julian Reschke</span>, <span class="contact-name">David Schinazi</span>, <span class="contact-name">Lucas Pardue</span>, and <span class="contact-name">Tommy Pauly</span> provided
excellent feedback on both the design and its documentation.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Martin Thomson</span></div>
<div dir="auto" class="left"><span class="org">Mozilla</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mt@lowentropy.net" class="email">mt@lowentropy.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Christopher A. Wood</span></div>
<div dir="auto" class="left"><span class="org">Cloudflare</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:caw@heapingbits.net" class="email">caw@heapingbits.net</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>