Ignore:
Timestamp:
31/01/13 02:23:50 (10 years ago)
Author:
martin.thomson@…
Message:

Adding decisions on flow control, removing versions.

Location:
draft-ietf-httpbis-http2/latest
Files:
2 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.html

    r2148 r2174  
    406406  }
    407407  @bottom-center {
    408        content: "Expires July 25, 2013";
     408       content: "Expires August 4, 2013";
    409409  }
    410410  @bottom-right {
    … …  
    447447      <meta name="dct.creator" content="Melnikov, A.">
    448448      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-http2-latest">
    449       <meta name="dct.issued" scheme="ISO8601" content="2013-01-21">
    450       <meta name="dct.abstract" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicted push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified.">
    451       <meta name="description" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicted push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified.">
     449      <meta name="dct.issued" scheme="ISO8601" content="2013-01-31">
     450      <meta name="dct.abstract" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicited push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified.">
     451      <meta name="description" content="This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicited push of resources from server to client. This document is an alternative to, but does not obsolete RFC{http-p1}. The HTTP protocol semantics described in RFC{http-p2..p7} are unmodified.">
    452452   </head>
    453453   <body onload="init();">
    … …  
    467467            </tr>
    468468            <tr>
    469                <td class="left">Expires: July 25, 2013</td>
     469               <td class="left">Expires: August 4, 2013</td>
    470470               <td class="right">Google, Inc</td>
    471471            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">January 21, 2013</td>
     490               <td class="right">January 31, 2013</td>
    491491            </tr>
    492492         </tbody>
    … …  
    495495      <h1 id="rfc.abstract"><a href="#rfc.abstract">Abstract</a></h1>
    496496      <p>This document describes an optimised expression of the semantics of the HTTP protocol. The HTTP/2.0 encapsulation enables
    497          more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicted push
     497         more efficient transfer of resources over HTTP by providing compressed headers, simultaneous requests, and unsolicited push
    498498         of resources from server to client.
    499499      </p> 
    … …  
    510510      <p>The current issues list is at &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/report/21">http://tools.ietf.org/wg/httpbis/trac/report/21</a>&gt; and related documents (including fancy diffs) can be found at &lt;<a href="http://tools.ietf.org/wg/httpbis/">http://tools.ietf.org/wg/httpbis/</a>&gt;.
    511511      </p> 
    512       <p>The changes in this draft are summarized in <a href="#changes.since.draft-ietf-httpbis-http2-00" title="Since draft-ietf-httpbis-http2-00">Appendix&nbsp;A.1</a>.
     512      <p>The changes in this draft are summarized in <a href="#changes.since.draft-ietf-httpbis-http2-01" title="Since draft-ietf-httpbis-http2-01">Appendix&nbsp;A.1</a>.
    513513      </p>
    514514      <h1><a id="rfc.status" href="#rfc.status">Status of This Memo</a></h1>
    … …  
    521521         in progress”.
    522522      </p>
    523       <p>This Internet-Draft will expire on July 25, 2013.</p>
     523      <p>This Internet-Draft will expire on August 4, 2013.</p>
    524524      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    525525      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    642642         <li><a href="#rfc.authors">Authors' Addresses</a></li>
    643643         <li><a href="#rfc.section.A">A.</a>&nbsp;&nbsp;&nbsp;<a href="#change.log">Change Log (to be removed by RFC Editor before publication)</a><ul>
    644                <li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.draft-ietf-httpbis-http2-00">Since draft-ietf-httpbis-http2-00</a></li>
    645                <li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.draft-mbelshe-httpbis-spdy-00">Since draft-mbelshe-httpbis-spdy-00</a></li>
     644               <li><a href="#rfc.section.A.1">A.1</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.draft-ietf-httpbis-http2-01">Since draft-ietf-httpbis-http2-01</a></li>
     645               <li><a href="#rfc.section.A.2">A.2</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.draft-ietf-httpbis-http2-00">Since draft-ietf-httpbis-http2-00</a></li>
     646               <li><a href="#rfc.section.A.3">A.3</a>&nbsp;&nbsp;&nbsp;<a href="#changes.since.draft-mbelshe-httpbis-spdy-00">Since draft-mbelshe-httpbis-spdy-00</a></li>
    646647            </ul>
    647648         </li>
    … …  
    698699      </p>
    699700      <h2 id="rfc.section.2.1"><a href="#rfc.section.2.1">2.1</a>&nbsp;<a id="versioning" href="#versioning">HTTP/2.0 Version Identification</a></h2>
    700       <p id="rfc.section.2.1.p.1">HTTP/2.0 is identified in using the string "HTTP/2.0". This identification is used in the HTTP/1.1 Upgrade header, in the <a href="#TLSNPN">TLS-NPN</a> <cite title="TLS Next Protocol Negotiation" id="rfc.xref.TLSNPN.1">[TLSNPN]</cite> [[TBD]] field and other places where protocol identification is required.
    701       </p>
    702       <p id="rfc.section.2.1.p.2">[[Editor's Note: please remove the following text prior to the publication of a final version of this document.]]</p>
    703       <p id="rfc.section.2.1.p.3">Only implementations of the final, published RFC can identify themselves as "HTTP/2.0". Until such an RFC exists, implementations
     701      <p id="rfc.section.2.1.p.1">HTTP/2.0 is identified using the string "HTTP/2.0". This identification is used in the HTTP/1.1 Upgrade header, in the <a href="#TLSNPN">TLS-NPN</a> <cite title="TLS Next Protocol Negotiation" id="rfc.xref.TLSNPN.1">[TLSNPN]</cite> [[TBD]] field and other places where protocol identification is required.
     702      </p>
     703      <p id="rfc.section.2.1.p.2">Negotiating "HTTP/2.0" implies the use of the transport, security, framing and message semantics described in this document.</p>
     704      <p id="rfc.section.2.1.p.3">[[Editor's Note: please remove the following text prior to the publication of a final version of this document.]]</p>
     705      <p id="rfc.section.2.1.p.4">Only implementations of the final, published RFC can identify themselves as "HTTP/2.0". Until such an RFC exists, implementations
    704706         MUST NOT identify themselves using "HTTP/2.0".
    705707      </p>
    706       <p id="rfc.section.2.1.p.4">Examples and text throughout the rest of this document use "HTTP/2.0" as a matter of editorial convenience only. Implementations
     708      <p id="rfc.section.2.1.p.5">Examples and text throughout the rest of this document use "HTTP/2.0" as a matter of editorial convenience only. Implementations
    707709         of draft versions MUST NOT identify using this string.
    708710      </p>
    709       <p id="rfc.section.2.1.p.5">Implementations of draft versions of the protocol MUST add the corresponding draft number to the identifier before the separator
     711      <p id="rfc.section.2.1.p.6">Implementations of draft versions of the protocol MUST add the corresponding draft number to the identifier before the separator
    710712         ('/'). For example, draft-ietf-httpbis-http2-03 is identified using the string "HTTP-03/2.0".
    711713      </p>
    712       <p id="rfc.section.2.1.p.6">Non-compatible experiments that are based on these draft versions MUST include a further identifier. For example, an experimental
     714      <p id="rfc.section.2.1.p.7">Non-compatible experiments that are based on these draft versions MUST include a further identifier. For example, an experimental
    713715         implementation of packet mood-based encoding based on draft-ietf-httpbis-http2-07 might identify itself as "HTTP-07-emo/2.0".
    714716         Note that any label MUST conform with the "token" syntax defined in Section 3.2.4 of <a href="#HTTP-p1" id="rfc.xref.HTTP-p1.2"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[HTTP-p1]</cite></a>. Experimenters are encouraged to coordinate their experiments on the ietf-http-wg@w3.org mailing list.
    … …  
    757759      <p id="rfc.section.3.2.p.1">Once the connection is established, clients and servers exchange framed messages. There are two types of frames: control frames (<a href="#ControlFrames" title="Control frames">Section&nbsp;3.2.1</a>) and data frames (<a href="#DataFrames" title="Data frames">Section&nbsp;3.2.2</a>). Frames always have a common header which is 8 bytes in length.
    758760      </p>
    759       <p id="rfc.section.3.2.p.2">The first bit is a control bit indicating whether a frame is a control frame or data frame. Control frames carry a version
    760          number, a frame type, flags, and a length. Data frames contain the stream ID, flags, and the length for the payload carried
    761          after the common header. The simple header is designed to make reading and writing of frames easy.
    762       </p>
    763       <p id="rfc.section.3.2.p.3">All integer values, including length, version, and type, are in network byte order. HTTP/2.0 does not enforce alignment of
    764          types in dynamically sized frames.
     761      <p id="rfc.section.3.2.p.2">The first bit is a control bit indicating whether a frame is a control frame or data frame. Control frames carry a frame type,
     762         flags, and a length. Data frames contain the stream ID, flags, and the length for the payload carried after the common header.
     763         The simple header is designed to make reading and writing of frames easy.
     764      </p>
     765      <p id="rfc.section.3.2.p.3">All integer values, including length and type, are in network byte order. HTTP/2.0 does not enforce alignment of types in
     766         dynamically sized frames.
    765767      </p>
    766768      <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a>&nbsp;<a id="ControlFrames" href="#ControlFrames">Control frames</a></h3>
    767769      <div id="rfc.figure.u.4"></div> <pre>+----------------------------------+
    768 |C| Version(15bits) | Type(16bits) |
     770|C| Unused (15bits) | Type(16bits) |
    769771+----------------------------------+
    770772| Flags (8)  |  Length (24 bits)   |
    … …  
    775777         1.
    776778      </p>
    777       <p id="rfc.section.3.2.1.p.3">Version: The version number of the HTTP/2.0 protocol. This document describes HTTP/2.0 version 3.</p>
     779      <p id="rfc.section.3.2.1.p.3">Unused: these 15 bits are unused.</p>
    778780      <p id="rfc.section.3.2.1.p.4">Type: The type of control frame. See Control Frames for the complete list of control frames.</p>
    779781      <p id="rfc.section.3.2.1.p.5">Flags: Flags related to this frame. Flags for control frames and data frames are different.</p>
    … …  
    949951      </p>
    950952      <p id="rfc.section.3.5.1.p.2">HTTP/2.0 stream flow control aims to allow for future improvements to flow control algorithms without requiring protocol changes.
    951          The following principles guide the HTTP/2.0 design:
     953         Flow control in HTTP/2.0 has the following characteristics:
    952954      </p>
    953955      <ol>
    … …  
    957959         </li>
    958960         <li>Flow control is directional with overall control provided by the receiver. A receiver MAY choose to set any window size that
    959             it desires for each stream [[TBD: ... and for the overall connection]]. A sender MUST respect flow control limits imposed
    960             by a receiver. Clients, servers and intermediaries all independently advertise their flow control preferences as a receiver
    961             and abide by the flow control limits set by their peer when sending.
    962          </li>
    963          <li>Flow control can be disabled by a receiver. A receiver can choose to either disable flow control, or to declare an infinite
    964             flow control limit. [[TBD: determine whether just one mechanism is sufficient, and then which alternative]]
     961            it desires for each stream and for the entire connection. A sender MUST respect flow control limits imposed by a receiver.
     962            Clients, servers and intermediaries all independently advertise their flow control preferences as a receiver and abide by
     963            the flow control limits set by their peer when sending.
     964         </li>
     965         <li>The initial value for the flow control window is 65536 bytes for both new streams and the overall connection.</li>
     966         <li>Flow control only applies to data frames. Control frames do not consume space in the advertised flow control window.</li>
     967         <li>Flow control can be disabled by a receiver. A receiver can choose to either disable flow control for a stream or connection
     968            by declaring an infinite flow control limit.
    965969         </li>
    966970         <li>HTTP/2.0 standardizes only the format of the window update message (<a href="#WINDOW_UPDATE" title="WINDOW_UPDATE">Section&nbsp;3.6.8</a>). This does not stipulate how a receiver decides when to send this message or the value that it sends. Nor does it specify
    … …  
    984988      </p>
    985989      <div id="rfc.figure.u.6"></div> <pre>+------------------------------------+
    986 |1|    version    |         1        |
     990|1|    unused     |         1        |
    987991+------------------------------------+
    988992|  Flags (8)  |  Length (24 bits)    |
    … …  
    10331037      <p id="rfc.section.3.6.2.p.1">SYN_REPLY indicates the acceptance of a stream creation by the recipient of a SYN_STREAM frame.</p>
    10341038      <div id="rfc.figure.u.7"></div> <pre>+------------------------------------+
    1035 |1|    version    |         2        |
     1039|1|    unused     |         2        |
    10361040+------------------------------------+
    10371041|  Flags (8)  |  Length (24 bits)    |
    … …  
    10721076      </p>
    10731077      <div id="rfc.figure.u.8"></div> <pre>+----------------------------------+
    1074 |1|   version    |         3       |
     1078|1|   unused     |         3       |
    10751079+----------------------------------+
    10761080| Flags (8)  |         8           |
    … …  
    10901094         <li>2 - INVALID_STREAM. This is returned when a frame is received for a stream which is not active.</li>
    10911095         <li>3 - REFUSED_STREAM. Indicates that the stream was refused before any processing has been done on the stream.</li>
    1092          <li>4 - UNSUPPORTED_VERSION. Indicates that the recipient of a stream does not support the HTTP/2.0 version requested.</li>
     1096         <li>4 - (UNUSED)</li>
    10931097         <li>5 - CANCEL. Used by the creator of a stream to indicate that the stream is no longer needed.</li>
    10941098         <li>6 - INTERNAL_ERROR. This is a generic error which can be used when the implementation has internally failed, not due to anything
    … …  
    11221126      </p>
    11231127      <div id="rfc.figure.u.9"></div> <pre>+----------------------------------+
    1124 |1|   version    |         4       |
     1128|1|   unused     |         4       |
    11251129+----------------------------------+
    11261130| Flags (8)  |  Length (24 bits)   |
    … …  
    11311135|             ...                  |
    11321136            </pre> <p id="rfc.section.3.6.4.p.4">Control bit: The control bit is always 1 for this message.</p>
    1133       <p id="rfc.section.3.6.4.p.5">Version: The HTTP/2.0 version number.</p>
     1137      <p id="rfc.section.3.6.4.p.5">Unused</p>
    11341138      <p id="rfc.section.3.6.4.p.6">Type: The message type for a SETTINGS message is 4.</p>
    11351139      <p id="rfc.section.3.6.4.p.7">Flags: FLAG_SETTINGS_CLEAR_SETTINGS (0x1): When set, the client should clear any previously persisted SETTINGS ID/Value pairs.
    … …  
    12041208      </p>
    12051209      <div id="rfc.figure.u.10"></div> <pre>+----------------------------------+
    1206 |1|   version    |         6       |
     1210|1|   unused     |         6       |
    12071211+----------------------------------+
    12081212| 0 (flags) |     4 (length)       |
    … …  
    12111215+----------------------------------+
    12121216            </pre> <p id="rfc.section.3.6.5.p.3">Control bit: The control bit is always 1 for this message.</p>
    1213       <p id="rfc.section.3.6.5.p.4">Version: The HTTP/2.0 version number.</p>
     1217      <p id="rfc.section.3.6.5.p.4">Unused</p>
    12141218      <p id="rfc.section.3.6.5.p.5">Type: The message type for a PING message is 6.</p>
    12151219      <p id="rfc.section.3.6.5.p.6">Length: This frame is always 4 bytes long.</p>
    … …  
    12421246      <p id="rfc.section.3.6.6.p.4">After sending a GOAWAY message, the sender must ignore all SYN_STREAM frames for new streams.</p>
    12431247      <div id="rfc.figure.u.11"></div> <pre>+----------------------------------+
    1244 |1|   version    |         7       |
     1248|1|   unused     |         7       |
    12451249+----------------------------------+
    12461250| 0 (flags) |     8 (length)       |
    … …  
    12511255+----------------------------------+
    12521256            </pre> <p id="rfc.section.3.6.6.p.6">Control bit: The control bit is always 1 for this message.</p>
    1253       <p id="rfc.section.3.6.6.p.7">Version: The HTTP/2.0 version number.</p>
     1257      <p id="rfc.section.3.6.6.p.7">Unused</p>
    12541258      <p id="rfc.section.3.6.6.p.8">Type: The message type for a GOAWAY message is 7.</p>
    12551259      <p id="rfc.section.3.6.6.p.9">Length: This frame is always 8 bytes long.</p>
    … …  
    12711275      </p>
    12721276      <div id="rfc.figure.u.12"></div> <pre>+------------------------------------+
    1273 |1|   version     |          8       |
     1277|1|   unused      |          8       |
    12741278+------------------------------------+
    12751279| Flags (8)  |   Length (24 bits)    |
    … …  
    13171321      </p>
    13181322      <div id="rfc.figure.u.13"></div> <pre>+----------------------------------+
    1319 |1|   version    |         9       |
     1323|1|   unused     |         9       |
    13201324+----------------------------------+
    13211325| 0 (flags) |     8 (length)       |
    … …  
    13261330+----------------------------------+
    13271331            </pre> <p id="rfc.section.3.6.8.p.4">Control bit: The control bit is always 1 for this message.</p>
    1328       <p id="rfc.section.3.6.8.p.5">Version: The HTTP/2.0 version number.</p>
     1332      <p id="rfc.section.3.6.8.p.5">Unused</p>
    13291333      <p id="rfc.section.3.6.8.p.6">Type: The message type for a WINDOW_UPDATE message is 9.</p>
    13301334      <p id="rfc.section.3.6.8.p.7">Length: The length field is always 8 for this frame (there are 8 bytes after the length field).</p>
    … …  
    17251729            <ul class="empty">
    17261730               <li>Although POSTs are inherently chunked, POST requests SHOULD also be accompanied by a Content-Length header. There are two
    1727                   reasons for this: First, it assists with upload progress meters for an improved user experience. But second, we know from
    1728                   early versions of HTTP/2.0 that failure to send a content length header is incompatible with many existing HTTP server implementations.
    1729                   Existing user-agents do not omit the Content-Length header, and server implementations have come to depend upon this.
     1731                  reasons for this: First, it assists with upload progress meters for an improved user experience. More importantly, failure
     1732                  to send a Content-Length header is incompatible with many existing HTTP server implementations. Existing user agents do not
     1733                  omit the Content-Length header, and server implementations have come to depend upon this.
    17301734               </li>
    17311735            </ul>
    … …  
    21162120      </div>
    21172121      <h1 id="rfc.section.A" class="np"><a href="#rfc.section.A">A.</a>&nbsp;<a id="change.log" href="#change.log">Change Log (to be removed by RFC Editor before publication)</a></h1>
    2118       <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.since.draft-ietf-httpbis-http2-00" href="#changes.since.draft-ietf-httpbis-http2-00">Since draft-ietf-httpbis-http2-00</a></h2>
    2119       <p id="rfc.section.A.1.p.1">Changed title throughout.</p>
    2120       <p id="rfc.section.A.1.p.2">Removed section on Incompatibilities with SPDY draft#2.</p>
    2121       <p id="rfc.section.A.1.p.3">Changed INTERNAL_ERROR on GOAWAY to have a value of 2 &lt;<a href="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU">https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU</a>&gt;.
    2122       </p>
    2123       <p id="rfc.section.A.1.p.4">Replaced abstract and introduction.</p>
    2124       <p id="rfc.section.A.1.p.5">Added section on starting HTTP/2.0, including upgrade mechanism.</p>
    2125       <p id="rfc.section.A.1.p.6">Removed unused references.</p>
    2126       <p id="rfc.section.A.1.p.7">Added flow control principles (<a href="#fc-principles" title="Flow Control Principles">Section&nbsp;3.5.1</a>) based on &lt;<a href="http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01">http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01</a>&gt;.
    2127       </p>
    2128       <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.since.draft-mbelshe-httpbis-spdy-00" href="#changes.since.draft-mbelshe-httpbis-spdy-00">Since draft-mbelshe-httpbis-spdy-00</a></h2>
    2129       <p id="rfc.section.A.2.p.1">Adopted as base for draft-ietf-httpbis-http2.</p>
    2130       <p id="rfc.section.A.2.p.2">Updated authors/editors list.</p>
    2131       <p id="rfc.section.A.2.p.3">Added status note.</p>
     2122      <h2 id="rfc.section.A.1"><a href="#rfc.section.A.1">A.1</a>&nbsp;<a id="changes.since.draft-ietf-httpbis-http2-01" href="#changes.since.draft-ietf-httpbis-http2-01">Since draft-ietf-httpbis-http2-01</a></h2>
     2123      <p id="rfc.section.A.1.p.1">None yet</p>
     2124      <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a>&nbsp;<a id="changes.since.draft-ietf-httpbis-http2-00" href="#changes.since.draft-ietf-httpbis-http2-00">Since draft-ietf-httpbis-http2-00</a></h2>
     2125      <p id="rfc.section.A.2.p.1">Changed title throughout.</p>
     2126      <p id="rfc.section.A.2.p.2">Removed section on Incompatibilities with SPDY draft#2.</p>
     2127      <p id="rfc.section.A.2.p.3">Changed INTERNAL_ERROR on GOAWAY to have a value of 2 &lt;<a href="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU">https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU</a>&gt;.
     2128      </p>
     2129      <p id="rfc.section.A.2.p.4">Replaced abstract and introduction.</p>
     2130      <p id="rfc.section.A.2.p.5">Added section on starting HTTP/2.0, including upgrade mechanism.</p>
     2131      <p id="rfc.section.A.2.p.6">Removed unused references.</p>
     2132      <p id="rfc.section.A.2.p.7">Added flow control principles (<a href="#fc-principles" title="Flow Control Principles">Section&nbsp;3.5.1</a>) based on &lt;<a href="http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01">http://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01</a>&gt;.
     2133      </p>
     2134      <h2 id="rfc.section.A.3"><a href="#rfc.section.A.3">A.3</a>&nbsp;<a id="changes.since.draft-mbelshe-httpbis-spdy-00" href="#changes.since.draft-mbelshe-httpbis-spdy-00">Since draft-mbelshe-httpbis-spdy-00</a></h2>
     2135      <p id="rfc.section.A.3.p.1">Adopted as base for draft-ietf-httpbis-http2.</p>
     2136      <p id="rfc.section.A.3.p.2">Updated authors/editors list.</p>
     2137      <p id="rfc.section.A.3.p.3">Added status note.</p>
    21322138      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    21332139      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.T">T</a> <a href="#rfc.index.U">U</a>

  • draft-ietf-httpbis-http2/latest/draft-ietf-httpbis-http2.xml

    r2148 r2174  
    175175<section anchor="versioning" title="HTTP/2.0 Version Identification">
    176176<t>
    177   HTTP/2.0 is identified in using the string "HTTP/2.0".  This identification is used in the
     177  HTTP/2.0 is identified using the string "HTTP/2.0".  This identification is used in the
    178178  HTTP/1.1 Upgrade header, in the <xref target="TLSNPN">TLS-NPN</xref> [[TBD]] field and other
    179179  places where protocol identification is required.
     180</t>
     181<t>
     182  Negotiating "HTTP/2.0" implies the use of the transport, security, framing and message semantics
     183  described in this document.
    180184</t>
    181185<t>
    … …  
    267271<t>Once the connection is established, clients and servers exchange framed messages. There are two types of frames: <xref target="ControlFrames">control frames</xref> and <xref target="DataFrames">data frames</xref>.  Frames always have a common header which is 8 bytes in length.</t>
    268272
    269 <t>The first bit is a control bit indicating whether a frame is a control frame or data frame. Control frames carry a version number, a frame type, flags, and a length. Data frames contain the stream ID, flags, and the length for the payload carried after the common header. The simple header is designed to make reading and writing of frames easy.</t>
    270 
    271 <t>All integer values, including length, version, and type, are in network byte order.  HTTP/2.0 does not enforce alignment of types in dynamically sized frames.</t>
     273<t>The first bit is a control bit indicating whether a frame is a control frame or data frame. Control frames carry a frame type, flags, and a length. Data frames contain the stream ID, flags, and the length for the payload carried after the common header. The simple header is designed to make reading and writing of frames easy.</t>
     274
     275<t>All integer values, including length and type, are in network byte order.  HTTP/2.0 does not enforce alignment of types in dynamically sized frames.</t>
    272276        <section anchor="ControlFrames" title="Control frames">
    273277<figure>
    274278  <artwork>
    275279+----------------------------------+
    276 |C| Version(15bits) | Type(16bits) |
     280|C| Unused (15bits) | Type(16bits) |
    277281+----------------------------------+
    278282| Flags (8)  |  Length (24 bits)   |
    … …  
    284288<t>Control bit: The 'C' bit is a single bit indicating if this is a control message. For control frames this value is always 1.</t>
    285289
    286 <t>Version: The version number of the HTTP/2.0 protocol.  This document describes HTTP/2.0 version 3.</t>
     290<t>
     291  Unused: these 15 bits are unused.
     292</t>
    287293
    288294<t>Type: The type of control frame. See Control Frames for the complete list of control frames.</t>
    … …  
    447453<t>
    448454  HTTP/2.0 stream flow control aims to allow for future improvements to flow control algorithms
    449   without requiring protocol changes.  The following principles guide the HTTP/2.0 design:
     455  without requiring protocol changes.  Flow control in HTTP/2.0 has the following characteristics:
    450456  <list style="numbers">
    451457    <t>
    … …  
    453459    </t>
    454460    <t>
    455       Flow control is based on window update messages.  Receivers advertise how many octets they are
    456       prepared to receive on a stream.  This is a credit-based scheme.
     461      Flow control is based on window update messages.  Receivers advertise how many octets they
     462      are prepared to receive on a stream.  This is a credit-based scheme.
    457463    </t>
    458464    <t>
    459465      Flow control is directional with overall control provided by the receiver.  A receiver MAY
    460       choose to set any window size that it desires for each stream [[TBD: ... and for the overall
    461       connection]].  A sender MUST respect flow control limits imposed by a receiver.  Clients,
     466      choose to set any window size that it desires for each stream and for the entire
     467      connection.  A sender MUST respect flow control limits imposed by a receiver.  Clients,
    462468      servers and intermediaries all independently advertise their flow control preferences as a
    463469      receiver and abide by the flow control limits set by their peer when sending.
    464470    </t>
    465471    <t>
     472      The initial value for the flow control window is 65536 bytes for both new streams and the
     473      overall connection.
     474    </t>
     475    <t>
     476      Flow control only applies to data frames.  Control frames do not consume space in the
     477      advertised flow control window.
     478    </t>
     479    <t>
    466480      Flow control can be disabled by a receiver.  A receiver can choose to either disable flow
    467       control, or to declare an infinite flow control limit.  [[TBD: determine whether just one
    468       mechanism is sufficient, and then which alternative]]
     481      control for a stream or connection by declaring an infinite flow control limit.
    469482    </t>
    470483    <t>
    … …  
    501514            <artwork>
    502515+------------------------------------+
    503 |1|    version    |         1        |
     516|1|    unused     |         1        |
    504517+------------------------------------+
    505518|  Flags (8)  |  Length (24 bits)    |
    … …  
    555568            <artwork>
    556569+------------------------------------+
    557 |1|    version    |         2        |
     570|1|    unused     |         2        |
    558571+------------------------------------+
    559572|  Flags (8)  |  Length (24 bits)    |
    … …  
    597610            <artwork>
    598611+----------------------------------+
    599 |1|   version    |         3       |
     612|1|   unused     |         3       |
    600613+----------------------------------+
    601614| Flags (8)  |         8           |
    … …  
    618631<t>2 - INVALID_STREAM. This is returned when a frame is received for a stream which is not active.</t>
    619632<t>3 - REFUSED_STREAM.  Indicates that the stream was refused before any processing has been done on the stream.</t>
    620 <t>4 - UNSUPPORTED_VERSION.  Indicates that the recipient of a stream does not support the HTTP/2.0 version requested.</t>
     633<t>4 - (UNUSED)</t>
    621634<t>5 - CANCEL.  Used by the creator of a stream to indicate that the stream is no longer needed.</t>
    622635<t>6 - INTERNAL_ERROR.  This is a generic error which can be used when the implementation has internally failed, not due to anything in the protocol.</t>
    … …  
    640653            <artwork>
    641654+----------------------------------+
    642 |1|   version    |         4       |
     655|1|   unused     |         4       |
    643656+----------------------------------+
    644657| Flags (8)  |  Length (24 bits)   |
    … …  
    652665<t>Control bit: The control bit is always 1 for this message.</t>
    653666
    654 <t>Version: The HTTP/2.0 version number.</t>
     667<t>
     668  Unused
     669</t>
    655670
    656671<t>Type: The message type for a SETTINGS message is 4.</t>
    … …  
    698713            <artwork>
    699714+----------------------------------+
    700 |1|   version    |         6       |
     715|1|   unused     |         6       |
    701716+----------------------------------+
    702717| 0 (flags) |     4 (length)       |
    … …  
    708723<t>Control bit: The control bit is always 1 for this message.</t>
    709724
    710 <t>Version: The HTTP/2.0 version number.</t>
     725<t>
     726  Unused
     727</t>
    711728
    712729<t>Type: The message type for a PING message is 6.</t>
    … …  
    733750            <artwork>
    734751+----------------------------------+
    735 |1|   version    |         7       |
     752|1|   unused     |         7       |
    736753+----------------------------------+
    737754| 0 (flags) |     8 (length)       |
    … …  
    745762<t>Control bit: The control bit is always 1 for this message.</t>
    746763
    747 <t>Version: The HTTP/2.0 version number.</t>
     764<t>
     765  Unused
     766</t>
    748767
    749768<t>Type: The message type for a GOAWAY message is 7.</t>
    … …  
    767786            <artwork>
    768787+------------------------------------+
    769 |1|   version     |          8       |
     788|1|   unused      |          8       |
    770789+------------------------------------+
    771790| Flags (8)  |   Length (24 bits)    |
    … …  
    807826            <artwork>
    808827+----------------------------------+
    809 |1|   version    |         9       |
     828|1|   unused     |         9       |
    810829+----------------------------------+
    811830| 0 (flags) |     8 (length)       |
    … …  
    819838<t>Control bit: The control bit is always 1 for this message.</t>
    820839
    821 <t>Version: The HTTP/2.0 version number.</t>
     840<t>
     841  Unused
     842</t>
    822843
    823844<t>Type: The message type for a WINDOW_UPDATE message is 9.</t>
    … …  
    11751196<t>POST-specific changes:
    11761197<list>
    1177 <t>Although POSTs are inherently chunked, POST requests SHOULD also be accompanied by a Content-Length header.  There are two reasons for this:  First, it assists with upload progress meters for an improved user experience.  But second, we know from early versions of HTTP/2.0 that failure to send a content length header is incompatible with many existing HTTP server implementations.  Existing user-agents do not omit the Content-Length header, and server implementations have come to depend upon this.</t>
     1198<t>Although POSTs are inherently chunked, POST requests SHOULD also be accompanied by a Content-Length header.  There are two reasons for this:  First, it assists with upload progress meters for an improved user experience.  More importantly, failure to send a Content-Length header is incompatible with many existing HTTP server implementations.  Existing user agents do not omit the Content-Length header, and server implementations have come to depend upon this.</t>
    11781199</list>
    11791200</t>
Note: See TracChangeset for help on using the changeset viewer.