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

Adding decisions on flow control, removing versions.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • 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.