File: rfc8673.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 (1822 lines) | stat: -rw-r--r-- 65,034 bytes
parent folder | download | duplicates (2)
<!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 8673: HTTP Random Access and Live Content</title>
<meta content="Craig Pratt" name="author">
<meta content="Darshak Thakore" name="author">
<meta content="Barbara Stark" name="author">
<meta content="
       
            To accommodate byte-range requests for content that has
            data appended over time, this document defines semantics
            that allow an HTTP client and a server to perform byte-range
      GET and HEAD requests that start at an arbitrary byte offset
      within the representation and end at an indeterminate offset.
       
    " name="description">
<meta content="xml2rfc 2.35.0" name="generator">
<meta content="http" name="keyword">
<meta content="range" name="keyword">
<meta content="live" name="keyword">
<meta content="aggregation" name="keyword">
<meta content="8673" name="rfc.number">
<link href="rfc8673.xml" type="application/rfc+xml" rel="alternate">
<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 {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  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.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;
}
#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;
  }
  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;
  }

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* 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: 0 0 0.25em 0;
  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;
}
/* 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 {
  .sourcecode {
    margin-bottom: 1em;
  }
}</style>
<link href="rfc-local.css" type="text/css" rel="stylesheet">
<link href="https://dx.doi.org/10.17487/rfc8673" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-httpbis-rand-access-live-04" 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 8673</td>
<td class="center">HTTP Random Access and Live Content</td>
<td class="right">November 2019</td>
</tr></thead>
<tfoot><tr>
<td class="left">Pratt, et al.</td>
<td class="center">Experimental</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/rfc8673" class="eref">8673</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Experimental</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2019-11" class="published">November 2019</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">C. Pratt</div>
</div>
<div class="author">
      <div class="author-name">D. Thakore</div>
<div class="org">CableLabs</div>
</div>
<div class="author">
      <div class="author-name">B. Stark</div>
<div class="org">AT&amp;T</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8673</h1>
<h1 id="title">HTTP Random Access and Live Content</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
            To accommodate byte-range requests for content that has
            data appended over time, this document defines semantics
            that allow an HTTP client and a server to perform byte-range
      GET and HEAD requests that start at an arbitrary byte offset
      within the representation and end at an indeterminate offset.<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 document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  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).  Not all documents
            approved by the IESG are candidates for any level of Internet
            Standard; see 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/rfc8673">https://www.rfc-editor.org/info/rfc8673</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) 2019 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 Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified 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="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-notational-conventions" class="xref">Notational Conventions</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-performing-range-requests-o" class="xref">Performing Range Requests on Random-Access Aggregating (Live) Content</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-establishing-the-randomly-a" class="xref">Establishing the Randomly Accessible Byte Range</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-byte-range-requests-beyond-" class="xref">Byte-Range Requests beyond the Randomly Accessible Byte Range</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc 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-other-applications-of-rando" class="xref">Other Applications of Random-Access Aggregating Content</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-requests-starting-at-the-ag" class="xref">Requests Starting at the Aggregation/Live Point</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc 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-shift-buffer-representation" class="xref">Shift-Buffer Representations</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc 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-recommendations-for-byte-ra" class="xref">Recommendations for Byte-Range Request last-byte-pos Values</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc 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-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc 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-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc 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-references" class="xref">References</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.7.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</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">
      Some Hypertext Transfer Protocol (HTTP) clients use byte-range requests
      (range requests using the "bytes" range unit) to transfer select
      portions of large representations <span>[<a href="#RFC7233" class="xref">RFC7233</a>]</span>. In some
      cases, large representations require content to be continuously or
      periodically appended, such as representations consisting of live audio 
      or video sources, blockchain databases, and log files. Clients cannot 
      access the appended/live content using a range request with the "bytes"
      range unit using the currently defined byte-range semantics without 
      accepting performance or behavior sacrifices that are not acceptable for 
      many applications.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
 For instance, HTTP clients have the ability to access appended content 
 on an indeterminate-length resource by transferring the entire 
 representation from the beginning and continuing to read the appended 
 content as it's made available. Obviously, this is highly inefficient 
 for cases where the representation is large and only the most recently 
 appended content is needed by the client.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3"> 
 Alternatively, clients can access appended
 content by sending periodic, open-ended byte-range
 requests using the last known end byte position as the
 range start. Performing low-frequency periodic
 byte-range requests in this fashion (polling) introduces
 latency since the client will necessarily be somewhat
 behind in transferring the aggregated content, effectively 
 resulting in the same kind of latency issues with the segmented content 
 transfer mechanisms in "HTTP Live Streaming" (HLS) <span>[<a href="#RFC8216" class="xref">RFC8216</a>]</span> and "Dynamic Adaptive Streaming
 over HTTP" <span>[<a href="#MPEG-DASH" class="xref">MPEG-DASH</a>]</span>.
 While performing 
        these range requests at higher frequency can reduce this latency, 
        it also incurs more processing overhead and HTTP exchanges as 
        many of the requests will return no content, since content is 
 usually aggregated in groups of bytes (e.g., a video frame, audio 
 sample, block, or log entry).<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
           This document describes a usage model for range requests that enables
           efficient retrieval of representations that are appended to over time
           by using large values and associated semantics for communicating
           range end positions. This model allows representations to be
           progressively delivered by servers as new content is added. It also
           ensures compatibility with servers and intermediaries that don't
           support this technique.<a href="#section-1-4" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-notational-conventions">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-notational-conventions" class="section-name selfRef">Notational Conventions</a>
        </h3>
<p id="section-1.1-1">This document cites Augmented Backus-Naur Form (ABNF) productions
            from <span>[<a href="#RFC7233" class="xref">RFC7233</a>]</span>, using the notation defined in <span>[<a href="#RFC5234" class="xref">RFC5234</a>]</span>.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="definition">
<section id="section-2">
      <h2 id="name-performing-range-requests-o">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-performing-range-requests-o" class="section-name selfRef">Performing Range Requests on Random-Access Aggregating (Live) Content</a>
      </h2>
<p id="section-2-1">
            This document recommends a two-step process for accessing resources
            that have indeterminate-length representations.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">
            Two steps are necessary because of limitations with the range request
            header fields and the Content-Range response header fields. A server cannot
            know from a range request that a client wishes to receive a response
            that does not have a definite end. More critically, the header fields
            do not allow the server to signal that a resource has indeterminate
            length without also providing a fixed portion of the resource.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">
            A client first learns that the resource has a representation of
            indeterminate length by requesting a range of the resource. The server
            responds with the range that is available but indicates that the
            length of the representation is unknown using the existing
            Content-Range syntax. See <a href="#establishing-range" class="xref">Section 2.1</a>
            for details and examples.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">
            Once the client knows the resource has indeterminate length, it can
            request a range with a very large end position from the resource. The
            client chooses an explicit end value larger than can be transferred in
            the foreseeable term. A server that supports range requests of
            indeterminate length signals its understanding of the client's
            indeterminate range request by indicating that the range it is
            providing has a range end that exactly matches the client's requested
            range end rather than a range that is bounded by what is currently
            available. See <a href="#live-range-requests" class="xref">Section 2.2</a> for details.<a href="#section-2-4" class="pilcrow">¶</a></p>
<div id="establishing-range">
<section id="section-2.1">
        <h3 id="name-establishing-the-randomly-a">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-establishing-the-randomly-a" class="section-name selfRef">Establishing the Randomly Accessible Byte Range</a>
        </h3>
<p id="section-2.1-1">
        Determining if a representation is continuously aggregating ("live")
 and determining the randomly accessible byte range can both be
 performed using the existing definition for an open-ended byte-range
 request. Specifically, <span><a href="https://www.rfc-editor.org/rfc/rfc7233#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC7233" class="xref">RFC7233</a>]</span> defines a byte-range request of the form:<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<div id="section-2.1-2">
<pre class="sourcecode lang-abnf">
   byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
</pre><a href="#section-2.1-2" class="pilcrow">¶</a>
</div>
<p id="section-2.1-3">
      which allows a client to send a HEAD request with a first-byte-pos and 
      leave last-byte-pos absent. A server that receives a satisfiable
      byte-range request (with first-byte-pos smaller than the current
      representation length) may respond with a 206 status code (Partial
      Content) with a Content-Range
      header field indicating the currently satisfiable byte range. For example:<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="request"' id="section-2.1-4">
<pre>
HEAD /resource HTTP/1.1
Host: example.com
Range: bytes=0-
</pre><a href="#section-2.1-4" class="pilcrow">¶</a>
</div>
<p id="section-2.1-5">
      returns a response of the form:<a href="#section-2.1-5" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="response"' id="section-2.1-6">
<pre>
HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1234567/*
</pre><a href="#section-2.1-6" class="pilcrow">¶</a>
</div>
<p id="section-2.1-7">
      from the server indicating that (1) the complete representation length
      is unknown (via the "*" in place of the complete-length field) and (2)
      only bytes 0-1234567 were accessible at the time the request was
      processed by the server. The client can infer from this response that
      bytes 0-1234567 of the representation can be requested and transfer
      can be performed immediately.<a href="#section-2.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="live-range-requests">
<section id="section-2.2">
        <h3 id="name-byte-range-requests-beyond-">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-byte-range-requests-beyond-" class="section-name selfRef">Byte-Range Requests beyond the Randomly Accessible Byte Range</a>
        </h3>
<p id="section-2.2-1">
        Once a client has determined that a representation has an
 indeterminate length and established the byte range that can be
 accessed, it may want to perform a request with a start position
 within the randomly accessible content range and an end position 
 at an indefinite/live point -- a point where the byte-range GET 
 request is fulfilled on-demand as the content is aggregated.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">
        For example, for a large video asset, a client may wish to start a 
 content transfer from the video "key" frame immediately before the 
 point of aggregation and continue the content transfer indefinitely 
 as content is aggregated, in order to support low-latency startup 
 of a live video stream.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3">
        Unlike a byte-range request header field, a byte-content-range response
        header field cannot be "open-ended", per <span><a href="https://www.rfc-editor.org/rfc/rfc7233#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC7233" class="xref">RFC7233</a>]</span>:<a href="#section-2.2-3" class="pilcrow">¶</a></p>
<div id="section-2.2-4">
<pre class="sourcecode lang-abnf">
   byte-content-range  = bytes-unit SP
                        ( byte-range-resp / unsatisfied-range )

   byte-range-resp     = byte-range "/" ( complete-length / "*" )
   byte-range          = first-byte-pos "-" last-byte-pos
   unsatisfied-range   = "*/" complete-length

   complete-length     = 1*DIGIT
</pre><a href="#section-2.2-4" class="pilcrow">¶</a>
</div>
<p id="section-2.2-5">
        Specifically, last-byte-pos is required in byte-range. So, in order 
 to preserve interoperability with existing HTTP clients, servers, 
 proxies, and caches, this document proposes a mechanism for a client 
 to indicate support for handling an indeterminate-length byte-range 
 response and a mechanism for a server to indicate if/when it's 
 providing an indeterminate-length response.<a href="#section-2.2-5" class="pilcrow">¶</a></p>
<p id="section-2.2-6">
        A client can indicate support for handling indeterminate-length 
 byte-range responses by providing a very large value for the 
 last-byte-pos in the byte-range request. For example, a client can 
 perform a byte-range GET request of the form:<a href="#section-2.2-6" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="request"' id="section-2.2-7">
<pre>
GET /resource HTTP/1.1
Host: example.com
Range: bytes=1230000-999999999999
</pre><a href="#section-2.2-7" class="pilcrow">¶</a>
</div>
<p id="section-2.2-8">
        where the last-byte-pos in the request is much larger than the 
 last-byte-pos returned in response to an open-ended byte-range 
 HEAD request, as described above, and much larger than the expected 
 maximum size of the representation. See <a href="#Security" class="xref">Section 6</a> for 
 range value considerations.<a href="#section-2.2-8" class="pilcrow">¶</a></p>
<p id="section-2.2-9">
        In response, a server may indicate that it is supplying a continuously 
 aggregating/live response by supplying the client request's 
 last-byte-pos in the Content-Range response header field.<a href="#section-2.2-9" class="pilcrow">¶</a></p>
<p id="section-2.2-10">
        For example:<a href="#section-2.2-10" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="request"' id="section-2.2-11">
<pre>
GET /resource HTTP/1.1
Host: example.com
Range: bytes=1230000-999999999999
</pre><a href="#section-2.2-11" class="pilcrow">¶</a>
</div>
<p id="section-2.2-12">
        returns<a href="#section-2.2-12" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="response"' id="section-2.2-13">
<pre>
HTTP/1.1 206 Partial Content
Content-Range: bytes 1230000-999999999999/*
</pre><a href="#section-2.2-13" class="pilcrow">¶</a>
</div>
<p id="section-2.2-14">
        from the server to indicate that the response will start at byte
 1230000 and continue indefinitely to include all aggregated content, as it becomes available.<a href="#section-2.2-14" class="pilcrow">¶</a></p>
<p id="section-2.2-15">
        A server that doesn't support or supply a continuously aggregating/live 
 response will supply the currently satisfiable byte range, 
 as it would with an open-ended byte request.<a href="#section-2.2-15" class="pilcrow">¶</a></p>
<p id="section-2.2-16">
        For example:<a href="#section-2.2-16" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="request"' id="section-2.2-17">
<pre>
GET /resource HTTP/1.1
Host: example.com
Range: bytes=1230000-999999999999
</pre><a href="#section-2.2-17" class="pilcrow">¶</a>
</div>
<p id="section-2.2-18">
        returns<a href="#section-2.2-18" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="response"' id="section-2.2-19">
<pre>
HTTP/1.1 206 Partial Content
Content-Range: bytes 1230000-1234567/*
</pre><a href="#section-2.2-19" class="pilcrow">¶</a>
</div>
<p id="section-2.2-20">
        from the server to indicate that the response will start at byte
 1230000, end at byte 1234567, and not include any aggregated content. 
 This is the response expected from a typical HTTP server -- one that 
 doesn't support byte-range requests on aggregating content.<a href="#section-2.2-20" class="pilcrow">¶</a></p>
<p id="section-2.2-21">
        A client that doesn't receive a response indicating it is continuously 
 aggregating must use other means to access aggregated content (e.g., 
 periodic byte-range polling).<a href="#section-2.2-21" class="pilcrow">¶</a></p>
<p id="section-2.2-22">
        A server that does return a continuously aggregating/live response
 should return data using chunked transfer coding and not provide a
 Content-Length header field. A 0-length chunk indicates the end of the
 transfer, per <span><a href="https://www.rfc-editor.org/rfc/rfc7230#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC7230" class="xref">RFC7230</a>]</span>.<a href="#section-2.2-22" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="other-applications">
<section id="section-3">
      <h2 id="name-other-applications-of-rando">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-other-applications-of-rando" class="section-name selfRef">Other Applications of Random-Access Aggregating Content</a>
      </h2>
<div id="starting-at-live">
<section id="section-3.1">
        <h3 id="name-requests-starting-at-the-ag">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-requests-starting-at-the-ag" class="section-name selfRef">Requests Starting at the Aggregation/Live Point</a>
        </h3>
<p id="section-3.1-1">
          A client that wishes to only receive newly aggregated portions of a
          resource (i.e., start at the live point) can use a HEAD request to
          learn what range the server has currently available and initiate an
          indeterminate-length transfer. For example:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="request"' id="section-3.1-2">
<pre>
HEAD /resource HTTP/1.1
Host: example.com
Range: bytes=0-
</pre><a href="#section-3.1-2" class="pilcrow">¶</a>
</div>
<p id="section-3.1-3">
            with the Content-Range response header field indicating the range
     (or ranges) available. For example:<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="response"' id="section-3.1-4">
<pre>
206 Partial Content
Content-Range: bytes 0-1234567/*
</pre><a href="#section-3.1-4" class="pilcrow">¶</a>
</div>
<p id="section-3.1-5">
            The client can then issue a request for a range starting at the end
            value (using a very large value for the end of a range) and receive
            only new content.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
<p id="section-3.1-6">
          For example:<a href="#section-3.1-6" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="request"' id="section-3.1-7">
<pre>
GET /resource HTTP/1.1
Host: example.com
Range: bytes=1234567-999999999999
</pre><a href="#section-3.1-7" class="pilcrow">¶</a>
</div>
<p id="section-3.1-8">
          with a server returning a Content-Range response indicating that an
   indeterminate-length response body will be provided:<a href="#section-3.1-8" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="response"' id="section-3.1-9">
<pre>
206 Partial Content
Content-Range: bytes 1234567-999999999999/*
</pre><a href="#section-3.1-9" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="shift-buffers">
<section id="section-3.2">
        <h3 id="name-shift-buffer-representation">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-shift-buffer-representation" class="section-name selfRef">Shift-Buffer Representations</a>
        </h3>
<p id="section-3.2-1">
        Some representations lend themselves to front-end content removal in
 addition to aggregation. While still supporting random access,
 representations of this type have a portion at the beginning (the "0"
 end) of the randomly accessible region that becomes inaccessible over
 time. Examples of this kind of representation would be an audio-video 
 time-shift buffer or a rolling log file.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">
        For example, a range request containing:<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="request"' id="section-3.2-3">
<pre>
HEAD /resource HTTP/1.1
Host: example.com
Range: bytes=0-
</pre><a href="#section-3.2-3" class="pilcrow">¶</a>
</div>
<p id="section-3.2-4">
        returns<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="response"' id="section-3.2-5">
<pre>
206 Partial Content
Content-Range: bytes 1000000-1234567/*
</pre><a href="#section-3.2-5" class="pilcrow">¶</a>
</div>
<p id="section-3.2-6">
        indicating that the first 1000000 bytes were not accessible at the
 time the HEAD request was processed. Subsequent HEAD requests could return:<a href="#section-3.2-6" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft art-example" id="section-3.2-7">
<pre>
Content-Range: bytes 1000000-1234567/*
</pre><a href="#section-3.2-7" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft art-example" id="section-3.2-8">
<pre>
Content-Range: bytes 1010000-1244567/*
</pre><a href="#section-3.2-8" class="pilcrow">¶</a>
</div>
<div class="artwork art-text alignLeft art-example" id="section-3.2-9">
<pre>
Content-Range: bytes 1020000-1254567/*
</pre><a href="#section-3.2-9" class="pilcrow">¶</a>
</div>
<p id="section-3.2-10">
        Note though that the difference between the first-byte-pos and 
 last-byte-pos need not be constant.<a href="#section-3.2-10" class="pilcrow">¶</a></p>
<p id="section-3.2-11">
        The client could then follow up with a GET range request containing:<a href="#section-3.2-11" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="request"' id="section-3.2-12">
<pre>
GET /resource HTTP/1.1
Host: example.com
Range: bytes=1020000-999999999999
</pre><a href="#section-3.2-12" class="pilcrow">¶</a>
</div>
<p id="section-3.2-13">
        with the server returning<a href="#section-3.2-13" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="response"' id="section-3.2-14">
<pre>
206 Partial Content
Content-Range: bytes 1020000-999999999999/*
</pre><a href="#section-3.2-14" class="pilcrow">¶</a>
</div>
<p id="section-3.2-15">
        with the response body returning bytes 1020000-1254567 immediately 
 and aggregated/live data being returned as the content is aggregated.<a href="#section-3.2-15" class="pilcrow">¶</a></p>
<p id="section-3.2-16">
        A server that doesn't support or supply a continuously aggregating/live
 response will supply the currently satisfiable byte range, as
 it would with an open-ended byte request. For example:<a href="#section-3.2-16" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="request"' id="section-3.2-17">
<pre>
GET /resource HTTP/1.1
Host: example.com
Range: bytes=0-999999999999
</pre><a href="#section-3.2-17" class="pilcrow">¶</a>
</div>
<p id="section-3.2-18">
        returns<a href="#section-3.2-18" class="pilcrow">¶</a></p>
<div class='artwork art-text alignLeft art-message/http; msgtype="response"' id="section-3.2-19">
<pre>
HTTP/1.1 206 Partial Content
Content-Range: bytes 1020000-1254567/*
</pre><a href="#section-3.2-19" class="pilcrow">¶</a>
</div>
<p id="section-3.2-20">
        from the server to indicate that the response will start at byte
 1020000, end at byte 1254567, and not include any aggregated 
 content. This is the response expected from a typical HTTP 
 server -- one that doesn't support byte-range requests on aggregating content.<a href="#section-3.2-20" class="pilcrow">¶</a></p>
<p id="section-3.2-21">
          Note that responses to GET requests performed on shift-buffer
          representations using Range headers can be cached by intermediaries, since
          the Content-Range response header indicates which portion of the
          representation is being returned in the response body. However, GET
          requests without a Range header cannot be cached since the first
          byte of the response body can vary from request to request. To
          ensure GET requests without Range headers on shift-buffer representations
          are not cached, servers hosting a shift-buffer representation should
          either not return a 200-level response (e.g., send a 300-level
          redirect response with a URI that represents the current start of
          the shift buffer) or indicate the response is non-cacheable. See
          <span>[<a href="#RFC7234" class="xref">RFC7234</a>]</span> for details on HTTP cache control.<a href="#section-3.2-21" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="RecommendedVLV">
<section id="section-4">
      <h2 id="name-recommendations-for-byte-ra">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-recommendations-for-byte-ra" class="section-name selfRef">Recommendations for Byte-Range Request last-byte-pos Values</a>
      </h2>
<p id="section-4-1">
            While it would be ideal to define a single large last-byte-pos
            value for byte-range requests, there's no single value that would work for all
            applications and platforms. For example, JavaScript numbers cannot
            represent all integer values above 2^^53, so a JavaScript
            application may want to use 2^^53-1 for last-byte-pos. This
            value, however, would not be sufficient for all applications, such
            as long-duration high-bitrate streams. So 
            2^^53-1 (9007199254740991) is recommended as a last-byte-pos
            unless an application has a good justification to use a smaller or
            larger value. For example, if it is always known that the resource won't
            exceed a value smaller than the recommended last-byte-pos for
            an application, a smaller value can be used. If it's likely
            that an application will utilize resources larger than the
            recommended last-byte-pos (such as a continuously aggregating
            high-bitrate media stream), a larger value should be used.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
            Note that, in accordance with the semantics defined above, servers
     that support random-access live content will need to return the 
     last-byte-pos provided in the byte-range request in some cases -- even
     if the last-byte-pos cannot be represented as a numerical value 
     internally by the server. As is the case with any
     continuously aggregating/live resource, the server should
     terminate the content transfer when the end of the resource is 
     reached -- whether the end is due to termination of the content
     source or the content length exceeds the server's maximum representation length.<a href="#section-4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-5">
      <h2 id="name-iana-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-5-1">This document has no IANA actions.<a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="Security">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">
            As described above, servers need to be prepared to receive 
     last-byte-pos values in range requests that are numerically larger 
     than the server implementation supports and return these values in 
     Content-Range response header fields. Servers should check the 
     last-byte-pos value before converting and storing them into
     numeric form to ensure the value doesn't cause an overflow or
     index incorrect data. The simplest way to satisfy the live-range 
     semantics defined in this document without potential overflow
     issues is to store the last-byte-pos as a string value and return 
     it in the byte-range Content-Range response header's last-byte-pos field.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-7">
      <h2 id="name-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-7.1">
        <h3 id="name-normative-references">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC5234">[RFC5234]</dt>
        <dd>
<span class="refAuthor">Crocker, D., Ed.</span><span class="refAuthor"> and P. Overell</span>, <span class="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <span class="seriesInfo">STD 68</span>, <span class="seriesInfo">RFC 5234</span>, <span class="seriesInfo">DOI 10.17487/RFC5234</span>, <time datetime="2008-01">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</a>&gt;</span>. </dd>
<dt id="RFC7230">[RFC7230]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor"> and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"</span>, <span class="seriesInfo">RFC 7230</span>, <span class="seriesInfo">DOI 10.17487/RFC7230</span>, <time datetime="2014-06">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7230">https://www.rfc-editor.org/info/rfc7230</a>&gt;</span>. </dd>
<dt id="RFC7233">[RFC7233]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor">, Lafon, Y., Ed.</span><span class="refAuthor">, and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Range Requests"</span>, <span class="seriesInfo">RFC 7233</span>, <span class="seriesInfo">DOI 10.17487/RFC7233</span>, <time datetime="2014-06">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7233">https://www.rfc-editor.org/info/rfc7233</a>&gt;</span>. </dd>
<dt id="RFC7234">[RFC7234]</dt>
      <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor">, Nottingham, M., Ed.</span><span class="refAuthor">, and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Caching"</span>, <span class="seriesInfo">RFC 7234</span>, <span class="seriesInfo">DOI 10.17487/RFC7234</span>, <time datetime="2014-06">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7234">https://www.rfc-editor.org/info/rfc7234</a>&gt;</span>. </dd>
</dl>
</section>
<section id="section-7.2">
        <h3 id="name-informative-references">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="MPEG-DASH">[MPEG-DASH]</dt>
        <dd>
<span class="refAuthor">ISO</span>, <span class="refTitle">"Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats"</span>, <span class="seriesInfo">ISO/IEC 23009-1</span>, <time datetime="2019-08">August 2019</time>, <span>&lt;<a href="https://www.iso.org/standard/75485.html">https://www.iso.org/standard/75485.html</a>&gt;</span>. </dd>
<dt id="RFC8216">[RFC8216]</dt>
      <dd>
<span class="refAuthor">Pantos, R., Ed.</span><span class="refAuthor"> and W. May</span>, <span class="refTitle">"HTTP Live Streaming"</span>, <span class="seriesInfo">RFC 8216</span>, <span class="seriesInfo">DOI 10.17487/RFC8216</span>, <time datetime="2017-08">August 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8216">https://www.rfc-editor.org/info/rfc8216</a>&gt;</span>. </dd>
</dl>
</section>
</section>
<div id="Acknowledgements">
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">
      The authors would like to thank Mark Nottingham, Patrick McManus, Julian Reschke, Remy Lebeau, Rodger
      Combs, Thorsten Lohmar, Martin Thompson, Adrien de Croy, K. Morgan, Roy
      T. Fielding, and Jeremy Poulter.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-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">Craig Pratt</span></div>
<div dir="auto" class="left">
<span class="locality">Portland</span>, <span class="region">OR</span> <span class="postal-code">97229</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:pratt@acm.org" class="email">pratt@acm.org</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Darshak Thakore</span></div>
<div dir="auto" class="left"><span class="org">CableLabs</span></div>
<div dir="auto" class="left"><span class="street-address">858 Coal Creek Circle</span></div>
<div dir="auto" class="left">
<span class="locality">Louisville</span>, <span class="region">CO</span> <span class="postal-code">80027</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:d.thakore@cablelabs.com" class="email">d.thakore@cablelabs.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Barbara Stark</span></div>
<div dir="auto" class="left"><span class="org">AT&amp;T</span></div>
<div dir="auto" class="left">
<span class="locality">Atlanta</span>, <span class="region">GA</span> </div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:barbara.stark@att.com" class="email">barbara.stark@att.com</a>
</div>
</address>
</section>
</div>
<script>var toc = document.getElementById("toc");
var tocToggle = toc.querySelector("h2");
var tocNav = toc.querySelector("nav");

// mobile menu toggle
tocToggle.onclick = function(event) {
    if (window.innerWidth < 1024) {
 var tocNavDisplay = tocNav.currentStyle ? tocNav.currentStyle.display : getComputedStyle(tocNav, null).display;
 if (tocNavDisplay == "none") {
     tocNav.style.display = "block";
 } else {
     tocNav.style.display = "none";
 }
    }
}

// toc anchor scroll to anchor
tocNav.addEventListener("click", function (event) {
    event.preventDefault();
    if (event.target.nodeName == 'A') {
 if (window.innerWidth < 1024) {
     tocNav.style.display = "none";
 }
 var href = event.target.getAttribute("href");
 var anchorId = href.substr(1);
 var anchor =  document.getElementById(anchorId);
 anchor.scrollIntoView(true);
 window.history.pushState("","",href);
    }
});

// switch toc mode when window resized
window.onresize = function () {
    if (window.innerWidth < 1024) {
 tocNav.style.display = "none";
    } else {
 tocNav.style.display = "block";
    }
}
</script>
</body>
</html>