Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next

RFC 7540

Hypertext Transfer Protocol Version 2 (HTTP/2)

Pages: 96
Proposed STD
Part 2 of 5 – Pages 12 to 31
First   Prev   Next

Top   ToC   RFC7540 - Page 12   prevText
4.  HTTP Frames

   Once the HTTP/2 connection is established, endpoints can begin
   exchanging frames.

4.1.  Frame Format

   All frames begin with a fixed 9-octet header followed by a variable-
   length payload.

    |                 Length (24)                   |
    |   Type (8)    |   Flags (8)   |
    |R|                 Stream Identifier (31)                      |
    |                   Frame Payload (0...)                      ...

                          Figure 1: Frame Layout

   The fields of the frame header are defined as:

   Length:  The length of the frame payload expressed as an unsigned
      24-bit integer.  Values greater than 2^14 (16,384) MUST NOT be
      sent unless the receiver has set a larger value for

      The 9 octets of the frame header are not included in this value.
Top   ToC   RFC7540 - Page 13
   Type:  The 8-bit type of the frame.  The frame type determines the
      format and semantics of the frame.  Implementations MUST ignore
      and discard any frame that has a type that is unknown.

   Flags:  An 8-bit field reserved for boolean flags specific to the
      frame type.

      Flags are assigned semantics specific to the indicated frame type.
      Flags that have no defined semantics for a particular frame type
      MUST be ignored and MUST be left unset (0x0) when sending.

   R: A reserved 1-bit field.  The semantics of this bit are undefined,
      and the bit MUST remain unset (0x0) when sending and MUST be
      ignored when receiving.

   Stream Identifier:  A stream identifier (see Section 5.1.1) expressed
      as an unsigned 31-bit integer.  The value 0x0 is reserved for
      frames that are associated with the connection as a whole as
      opposed to an individual stream.

   The structure and content of the frame payload is dependent entirely
   on the frame type.

4.2.  Frame Size

   The size of a frame payload is limited by the maximum size that a
   receiver advertises in the SETTINGS_MAX_FRAME_SIZE setting.  This
   setting can have any value between 2^14 (16,384) and 2^24-1
   (16,777,215) octets, inclusive.

   All implementations MUST be capable of receiving and minimally
   processing frames up to 2^14 octets in length, plus the 9-octet frame
   header (Section 4.1).  The size of the frame header is not included
   when describing frame sizes.

      Note: Certain frame types, such as PING (Section 6.7), impose
      additional limits on the amount of payload data allowed.

   An endpoint MUST send an error code of FRAME_SIZE_ERROR if a frame
   exceeds the size defined in SETTINGS_MAX_FRAME_SIZE, exceeds any
   limit defined for the frame type, or is too small to contain
   mandatory frame data.  A frame size error in a frame that could alter
   the state of the entire connection MUST be treated as a connection
   error (Section 5.4.1); this includes any frame carrying a header
   block (Section 4.3) (that is, HEADERS, PUSH_PROMISE, and
   CONTINUATION), SETTINGS, and any frame with a stream identifier of 0.
Top   ToC   RFC7540 - Page 14
   Endpoints are not obligated to use all available space in a frame.
   Responsiveness can be improved by using frames that are smaller than
   the permitted maximum size.  Sending large frames can result in
   delays in sending time-sensitive frames (such as RST_STREAM,
   WINDOW_UPDATE, or PRIORITY), which, if blocked by the transmission of
   a large frame, could affect performance.

4.3.  Header Compression and Decompression

   Just as in HTTP/1, a header field in HTTP/2 is a name with one or
   more associated values.  Header fields are used within HTTP request
   and response messages as well as in server push operations (see
   Section 8.2).

   Header lists are collections of zero or more header fields.  When
   transmitted over a connection, a header list is serialized into a
   header block using HTTP header compression [COMPRESSION].  The
   serialized header block is then divided into one or more octet
   sequences, called header block fragments, and transmitted within the
   payload of HEADERS (Section 6.2), PUSH_PROMISE (Section 6.6), or
   CONTINUATION (Section 6.10) frames.

   The Cookie header field [COOKIE] is treated specially by the HTTP
   mapping (see Section

   A receiving endpoint reassembles the header block by concatenating
   its fragments and then decompresses the block to reconstruct the
   header list.

   A complete header block consists of either:

   o  a single HEADERS or PUSH_PROMISE frame, with the END_HEADERS flag
      set, or

   o  a HEADERS or PUSH_PROMISE frame with the END_HEADERS flag cleared
      and one or more CONTINUATION frames, where the last CONTINUATION
      frame has the END_HEADERS flag set.

   Header compression is stateful.  One compression context and one
   decompression context are used for the entire connection.  A decoding
   error in a header block MUST be treated as a connection error
   (Section 5.4.1) of type COMPRESSION_ERROR.

   Each header block is processed as a discrete unit.  Header blocks
   MUST be transmitted as a contiguous sequence of frames, with no
   interleaved frames of any other type or from any other stream.  The
   last frame in a sequence of HEADERS or CONTINUATION frames has the
Top   ToC   RFC7540 - Page 15
   END_HEADERS flag set.  The last frame in a sequence of PUSH_PROMISE
   or CONTINUATION frames has the END_HEADERS flag set.  This allows a
   header block to be logically equivalent to a single frame.

   Header block fragments can only be sent as the payload of HEADERS,
   PUSH_PROMISE, or CONTINUATION frames because these frames carry data
   that can modify the compression context maintained by a receiver.  An
   endpoint receiving HEADERS, PUSH_PROMISE, or CONTINUATION frames
   needs to reassemble header blocks and perform decompression even if
   the frames are to be discarded.  A receiver MUST terminate the
   connection with a connection error (Section 5.4.1) of type
   COMPRESSION_ERROR if it does not decompress a header block.

5.  Streams and Multiplexing

   A "stream" is an independent, bidirectional sequence of frames
   exchanged between the client and server within an HTTP/2 connection.
   Streams have several important characteristics:

   o  A single HTTP/2 connection can contain multiple concurrently open
      streams, with either endpoint interleaving frames from multiple

   o  Streams can be established and used unilaterally or shared by
      either the client or server.

   o  Streams can be closed by either endpoint.

   o  The order in which frames are sent on a stream is significant.
      Recipients process frames in the order they are received.  In
      particular, the order of HEADERS and DATA frames is semantically

   o  Streams are identified by an integer.  Stream identifiers are
      assigned to streams by the endpoint initiating the stream.
Top   ToC   RFC7540 - Page 16
5.1.  Stream States

   The lifecycle of a stream is shown in Figure 2.

                        send PP |        | recv PP
                       ,--------|  idle  |--------.
                      /         |        |         \
                     v          +--------+          v
              +----------+          |           +----------+
              |          |          | send H /  |          |
       ,------| reserved |          | recv H    | reserved |------.
       |      | (local)  |          |           | (remote) |      |
       |      +----------+          v           +----------+      |
       |          |             +--------+             |          |
       |          |     recv ES |        | send ES     |          |
       |   send H |     ,-------|  open  |-------.     | recv H   |
       |          |    /        |        |        \    |          |
       |          v   v         +--------+         v   v          |
       |      +----------+          |           +----------+      |
       |      |   half   |          |           |   half   |      |
       |      |  closed  |          | send R /  |  closed  |      |
       |      | (remote) |          | recv R    | (local)  |      |
       |      +----------+          |           +----------+      |
       |           |                |                 |           |
       |           | send ES /      |       recv ES / |           |
       |           | send R /       v        send R / |           |
       |           | recv R     +--------+   recv R   |           |
       | send R /  `----------->|        |<-----------'  send R / |
       | recv R                 | closed |               recv R   |
       `----------------------->|        |<----------------------'

          send:   endpoint sends this frame
          recv:   endpoint receives this frame

          H:  HEADERS frame (with implied CONTINUATIONs)
          PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
          ES: END_STREAM flag
          R:  RST_STREAM frame

                          Figure 2: Stream States

   Note that this diagram shows stream state transitions and the frames
   and flags that affect those transitions only.  In this regard,
   CONTINUATION frames do not result in state transitions; they are
   effectively part of the HEADERS or PUSH_PROMISE that they follow.
Top   ToC   RFC7540 - Page 17
   For the purpose of state transitions, the END_STREAM flag is
   processed as a separate event to the frame that bears it; a HEADERS
   frame with the END_STREAM flag set can cause two state transitions.

   Both endpoints have a subjective view of the state of a stream that
   could be different when frames are in transit.  Endpoints do not
   coordinate the creation of streams; they are created unilaterally by
   either endpoint.  The negative consequences of a mismatch in states
   are limited to the "closed" state after sending RST_STREAM, where
   frames might be received for some time after closing.

   Streams have the following states:

      All streams start in the "idle" state.

      The following transitions are valid from this state:

      *  Sending or receiving a HEADERS frame causes the stream to
         become "open".  The stream identifier is selected as described
         in Section 5.1.1.  The same HEADERS frame can also cause a
         stream to immediately become "half-closed".

      *  Sending a PUSH_PROMISE frame on another stream reserves the
         idle stream that is identified for later use.  The stream state
         for the reserved stream transitions to "reserved (local)".

      *  Receiving a PUSH_PROMISE frame on another stream reserves an
         idle stream that is identified for later use.  The stream state
         for the reserved stream transitions to "reserved (remote)".

      *  Note that the PUSH_PROMISE frame is not sent on the idle stream
         but references the newly reserved stream in the Promised Stream
         ID field.

      Receiving any frame other than HEADERS or PRIORITY on a stream in
      this state MUST be treated as a connection error (Section 5.4.1)
      of type PROTOCOL_ERROR.

   reserved (local):
      A stream in the "reserved (local)" state is one that has been
      promised by sending a PUSH_PROMISE frame.  A PUSH_PROMISE frame
      reserves an idle stream by associating the stream with an open
      stream that was initiated by the remote peer (see Section 8.2).
Top   ToC   RFC7540 - Page 18
      In this state, only the following transitions are possible:

      *  The endpoint can send a HEADERS frame.  This causes the stream
         to open in a "half-closed (remote)" state.

      *  Either endpoint can send a RST_STREAM frame to cause the stream
         to become "closed".  This releases the stream reservation.

      An endpoint MUST NOT send any type of frame other than HEADERS,
      RST_STREAM, or PRIORITY in this state.

      A PRIORITY or WINDOW_UPDATE frame MAY be received in this state.
      Receiving any type of frame other than RST_STREAM, PRIORITY, or
      WINDOW_UPDATE on a stream in this state MUST be treated as a
      connection error (Section 5.4.1) of type PROTOCOL_ERROR.

   reserved (remote):
      A stream in the "reserved (remote)" state has been reserved by a
      remote peer.

      In this state, only the following transitions are possible:

      *  Receiving a HEADERS frame causes the stream to transition to
         "half-closed (local)".

      *  Either endpoint can send a RST_STREAM frame to cause the stream
         to become "closed".  This releases the stream reservation.

      An endpoint MAY send a PRIORITY frame in this state to
      reprioritize the reserved stream.  An endpoint MUST NOT send any
      type of frame other than RST_STREAM, WINDOW_UPDATE, or PRIORITY in
      this state.

      Receiving any type of frame other than HEADERS, RST_STREAM, or
      PRIORITY on a stream in this state MUST be treated as a connection
      error (Section 5.4.1) of type PROTOCOL_ERROR.

      A stream in the "open" state may be used by both peers to send
      frames of any type.  In this state, sending peers observe
      advertised stream-level flow-control limits (Section 5.2).

      From this state, either endpoint can send a frame with an
      END_STREAM flag set, which causes the stream to transition into
      one of the "half-closed" states.  An endpoint sending an
Top   ToC   RFC7540 - Page 19
      END_STREAM flag causes the stream state to become "half-closed
      (local)"; an endpoint receiving an END_STREAM flag causes the
      stream state to become "half-closed (remote)".

      Either endpoint can send a RST_STREAM frame from this state,
      causing it to transition immediately to "closed".

   half-closed (local):
      A stream that is in the "half-closed (local)" state cannot be used
      for sending frames other than WINDOW_UPDATE, PRIORITY, and

      A stream transitions from this state to "closed" when a frame that
      contains an END_STREAM flag is received or when either peer sends
      a RST_STREAM frame.

      An endpoint can receive any type of frame in this state.
      Providing flow-control credit using WINDOW_UPDATE frames is
      necessary to continue receiving flow-controlled frames.  In this
      state, a receiver can ignore WINDOW_UPDATE frames, which might
      arrive for a short period after a frame bearing the END_STREAM
      flag is sent.

      PRIORITY frames received in this state are used to reprioritize
      streams that depend on the identified stream.

   half-closed (remote):
      A stream that is "half-closed (remote)" is no longer being used by
      the peer to send frames.  In this state, an endpoint is no longer
      obligated to maintain a receiver flow-control window.

      If an endpoint receives additional frames, other than
      WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in
      this state, it MUST respond with a stream error (Section 5.4.2) of
      type STREAM_CLOSED.

      A stream that is "half-closed (remote)" can be used by the
      endpoint to send frames of any type.  In this state, the endpoint
      continues to observe advertised stream-level flow-control limits
      (Section 5.2).

      A stream can transition from this state to "closed" by sending a
      frame that contains an END_STREAM flag or when either peer sends a
      RST_STREAM frame.
Top   ToC   RFC7540 - Page 20
      The "closed" state is the terminal state.

      An endpoint MUST NOT send frames other than PRIORITY on a closed
      stream.  An endpoint that receives any frame other than PRIORITY
      after receiving a RST_STREAM MUST treat that as a stream error
      (Section 5.4.2) of type STREAM_CLOSED.  Similarly, an endpoint
      that receives any frames after receiving a frame with the
      END_STREAM flag set MUST treat that as a connection error
      (Section 5.4.1) of type STREAM_CLOSED, unless the frame is
      permitted as described below.

      WINDOW_UPDATE or RST_STREAM frames can be received in this state
      for a short period after a DATA or HEADERS frame containing an
      END_STREAM flag is sent.  Until the remote peer receives and
      processes RST_STREAM or the frame bearing the END_STREAM flag, it
      might send frames of these types.  Endpoints MUST ignore
      WINDOW_UPDATE or RST_STREAM frames received in this state, though
      endpoints MAY choose to treat frames that arrive a significant
      time after sending END_STREAM as a connection error
      (Section 5.4.1) of type PROTOCOL_ERROR.

      PRIORITY frames can be sent on closed streams to prioritize
      streams that are dependent on the closed stream.  Endpoints SHOULD
      process PRIORITY frames, though they can be ignored if the stream
      has been removed from the dependency tree (see Section 5.3.4).

      If this state is reached as a result of sending a RST_STREAM
      frame, the peer that receives the RST_STREAM might have already
      sent -- or enqueued for sending -- frames on the stream that
      cannot be withdrawn.  An endpoint MUST ignore frames that it
      receives on closed streams after it has sent a RST_STREAM frame.
      An endpoint MAY choose to limit the period over which it ignores
      frames and treat frames that arrive after this time as being in

      Flow-controlled frames (i.e., DATA) received after sending
      RST_STREAM are counted toward the connection flow-control window.
      Even though these frames might be ignored, because they are sent
      before the sender receives the RST_STREAM, the sender will
      consider the frames to count against the flow-control window.

      An endpoint might receive a PUSH_PROMISE frame after it sends
      RST_STREAM.  PUSH_PROMISE causes a stream to become "reserved"
      even if the associated stream has been reset.  Therefore, a
      RST_STREAM is needed to close an unwanted promised stream.
Top   ToC   RFC7540 - Page 21
   In the absence of more specific guidance elsewhere in this document,
   implementations SHOULD treat the receipt of a frame that is not
   expressly permitted in the description of a state as a connection
   error (Section 5.4.1) of type PROTOCOL_ERROR.  Note that PRIORITY can
   be sent and received in any stream state.  Frames of unknown types
   are ignored.

   An example of the state transitions for an HTTP request/response
   exchange can be found in Section 8.1.  An example of the state
   transitions for server push can be found in Sections 8.2.1 and 8.2.2.

5.1.1.  Stream Identifiers

   Streams are identified with an unsigned 31-bit integer.  Streams
   initiated by a client MUST use odd-numbered stream identifiers; those
   initiated by the server MUST use even-numbered stream identifiers.  A
   stream identifier of zero (0x0) is used for connection control
   messages; the stream identifier of zero cannot be used to establish a
   new stream.

   HTTP/1.1 requests that are upgraded to HTTP/2 (see Section 3.2) are
   responded to with a stream identifier of one (0x1).  After the
   upgrade completes, stream 0x1 is "half-closed (local)" to the client.
   Therefore, stream 0x1 cannot be selected as a new stream identifier
   by a client that upgrades from HTTP/1.1.

   The identifier of a newly established stream MUST be numerically
   greater than all streams that the initiating endpoint has opened or
   reserved.  This governs streams that are opened using a HEADERS frame
   and streams that are reserved using PUSH_PROMISE.  An endpoint that
   receives an unexpected stream identifier MUST respond with a
   connection error (Section 5.4.1) of type PROTOCOL_ERROR.

   The first use of a new stream identifier implicitly closes all
   streams in the "idle" state that might have been initiated by that
   peer with a lower-valued stream identifier.  For example, if a client
   sends a HEADERS frame on stream 7 without ever sending a frame on
   stream 5, then stream 5 transitions to the "closed" state when the
   first frame for stream 7 is sent or received.

   Stream identifiers cannot be reused.  Long-lived connections can
   result in an endpoint exhausting the available range of stream
   identifiers.  A client that is unable to establish a new stream
   identifier can establish a new connection for new streams.  A server
   that is unable to establish a new stream identifier can send a GOAWAY
   frame so that the client is forced to open a new connection for new
Top   ToC   RFC7540 - Page 22
5.1.2.  Stream Concurrency

   A peer can limit the number of concurrently active streams using the
   SETTINGS_MAX_CONCURRENT_STREAMS parameter (see Section 6.5.2) within
   a SETTINGS frame.  The maximum concurrent streams setting is specific
   to each endpoint and applies only to the peer that receives the
   setting.  That is, clients specify the maximum number of concurrent
   streams the server can initiate, and servers specify the maximum
   number of concurrent streams the client can initiate.

   Streams that are in the "open" state or in either of the "half-
   closed" states count toward the maximum number of streams that an
   endpoint is permitted to open.  Streams in any of these three states
   count toward the limit advertised in the
   SETTINGS_MAX_CONCURRENT_STREAMS setting.  Streams in either of the
   "reserved" states do not count toward the stream limit.

   Endpoints MUST NOT exceed the limit set by their peer.  An endpoint
   that receives a HEADERS frame that causes its advertised concurrent
   stream limit to be exceeded MUST treat this as a stream error
   (Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM.  The choice
   of error code determines whether the endpoint wishes to enable
   automatic retry (see Section 8.1.4) for details).

   An endpoint that wishes to reduce the value of
   SETTINGS_MAX_CONCURRENT_STREAMS to a value that is below the current
   number of open streams can either close streams that exceed the new
   value or allow streams to complete.

5.2.  Flow Control

   Using streams for multiplexing introduces contention over use of the
   TCP connection, resulting in blocked streams.  A flow-control scheme
   ensures that streams on the same connection do not destructively
   interfere with each other.  Flow control is used for both individual
   streams and for the connection as a whole.

   HTTP/2 provides for flow control through use of the WINDOW_UPDATE
   frame (Section 6.9).
Top   ToC   RFC7540 - Page 23
5.2.1.  Flow-Control Principles

   HTTP/2 stream flow control aims to allow a variety of flow-control
   algorithms to be used without requiring protocol changes.  Flow
   control in HTTP/2 has the following characteristics:

   1.  Flow control is specific to a connection.  Both types of flow
       control are between the endpoints of a single hop and not over
       the entire end-to-end path.

   2.  Flow control is based on WINDOW_UPDATE frames.  Receivers
       advertise how many octets they are prepared to receive on a
       stream and for the entire connection.  This is a credit-based

   3.  Flow control is directional with overall control provided by the
       receiver.  A receiver MAY choose to set any window size that it
       desires for each stream and for the entire connection.  A sender
       MUST respect flow-control limits imposed by a receiver.  Clients,
       servers, and intermediaries all independently advertise their
       flow-control window as a receiver and abide by the flow-control
       limits set by their peer when sending.

   4.  The initial value for the flow-control window is 65,535 octets
       for both new streams and the overall connection.

   5.  The frame type determines whether flow control applies to a
       frame.  Of the frames specified in this document, only DATA
       frames are subject to flow control; all other frame types do not
       consume space in the advertised flow-control window.  This
       ensures that important control frames are not blocked by flow

   6.  Flow control cannot be disabled.

   7.  HTTP/2 defines only the format and semantics of the WINDOW_UPDATE
       frame (Section 6.9).  This document does not stipulate how a
       receiver decides when to send this frame or the value that it
       sends, nor does it specify how a sender chooses to send packets.
       Implementations are able to select any algorithm that suits their

   Implementations are also responsible for managing how requests and
   responses are sent based on priority, choosing how to avoid head-of-
   line blocking for requests, and managing the creation of new streams.
   Algorithm choices for these could interact with any flow-control
Top   ToC   RFC7540 - Page 24
5.2.2.  Appropriate Use of Flow Control

   Flow control is defined to protect endpoints that are operating under
   resource constraints.  For example, a proxy needs to share memory
   between many connections and also might have a slow upstream
   connection and a fast downstream one.  Flow-control addresses cases
   where the receiver is unable to process data on one stream yet wants
   to continue to process other streams in the same connection.

   Deployments that do not require this capability can advertise a flow-
   control window of the maximum size (2^31-1) and can maintain this
   window by sending a WINDOW_UPDATE frame when any data is received.
   This effectively disables flow control for that receiver.
   Conversely, a sender is always subject to the flow-control window
   advertised by the receiver.

   Deployments with constrained resources (for example, memory) can
   employ flow control to limit the amount of memory a peer can consume.
   Note, however, that this can lead to suboptimal use of available
   network resources if flow control is enabled without knowledge of the
   bandwidth-delay product (see [RFC7323]).

   Even with full awareness of the current bandwidth-delay product,
   implementation of flow control can be difficult.  When using flow
   control, the receiver MUST read from the TCP receive buffer in a
   timely fashion.  Failure to do so could lead to a deadlock when
   critical frames, such as WINDOW_UPDATE, are not read and acted upon.

5.3.  Stream Priority

   A client can assign a priority for a new stream by including
   prioritization information in the HEADERS frame (Section 6.2) that
   opens the stream.  At any other time, the PRIORITY frame
   (Section 6.3) can be used to change the priority of a stream.

   The purpose of prioritization is to allow an endpoint to express how
   it would prefer its peer to allocate resources when managing
   concurrent streams.  Most importantly, priority can be used to select
   streams for transmitting frames when there is limited capacity for

   Streams can be prioritized by marking them as dependent on the
   completion of other streams (Section 5.3.1).  Each dependency is
   assigned a relative weight, a number that is used to determine the
   relative proportion of available resources that are assigned to
   streams dependent on the same stream.
Top   ToC   RFC7540 - Page 25
   Explicitly setting the priority for a stream is input to a
   prioritization process.  It does not guarantee any particular
   processing or transmission order for the stream relative to any other
   stream.  An endpoint cannot force a peer to process concurrent
   streams in a particular order using priority.  Expressing priority is
   therefore only a suggestion.

   Prioritization information can be omitted from messages.  Defaults
   are used prior to any explicit values being provided (Section 5.3.5).

5.3.1.  Stream Dependencies

   Each stream can be given an explicit dependency on another stream.
   Including a dependency expresses a preference to allocate resources
   to the identified stream rather than to the dependent stream.

   A stream that is not dependent on any other stream is given a stream
   dependency of 0x0.  In other words, the non-existent stream 0 forms
   the root of the tree.

   A stream that depends on another stream is a dependent stream.  The
   stream upon which a stream is dependent is a parent stream.  A
   dependency on a stream that is not currently in the tree -- such as a
   stream in the "idle" state -- results in that stream being given a
   default priority (Section 5.3.5).

   When assigning a dependency on another stream, the stream is added as
   a new dependency of the parent stream.  Dependent streams that share
   the same parent are not ordered with respect to each other.  For
   example, if streams B and C are dependent on stream A, and if stream
   D is created with a dependency on stream A, this results in a
   dependency order of A followed by B, C, and D in any order.

       A                 A
      / \      ==>      /|\
     B   C             B D C

             Figure 3: Example of Default Dependency Creation

   An exclusive flag allows for the insertion of a new level of
   dependencies.  The exclusive flag causes the stream to become the
   sole dependency of its parent stream, causing other dependencies to
   become dependent on the exclusive stream.  In the previous example,
   if stream D is created with an exclusive dependency on stream A, this
   results in D becoming the dependency parent of B and C.
Top   ToC   RFC7540 - Page 26
       A                 |
      / \      ==>       D
     B   C              / \
                       B   C

            Figure 4: Example of Exclusive Dependency Creation

   Inside the dependency tree, a dependent stream SHOULD only be
   allocated resources if either all of the streams that it depends on
   (the chain of parent streams up to 0x0) are closed or it is not
   possible to make progress on them.

   A stream cannot depend on itself.  An endpoint MUST treat this as a
   stream error (Section 5.4.2) of type PROTOCOL_ERROR.

5.3.2.  Dependency Weighting

   All dependent streams are allocated an integer weight between 1 and
   256 (inclusive).

   Streams with the same parent SHOULD be allocated resources
   proportionally based on their weight.  Thus, if stream B depends on
   stream A with weight 4, stream C depends on stream A with weight 12,
   and no progress can be made on stream A, stream B ideally receives
   one-third of the resources allocated to stream C.

5.3.3.  Reprioritization

   Stream priorities are changed using the PRIORITY frame.  Setting a
   dependency causes a stream to become dependent on the identified
   parent stream.

   Dependent streams move with their parent stream if the parent is
   reprioritized.  Setting a dependency with the exclusive flag for a
   reprioritized stream causes all the dependencies of the new parent
   stream to become dependent on the reprioritized stream.

   If a stream is made dependent on one of its own dependencies, the
   formerly dependent stream is first moved to be dependent on the
   reprioritized stream's previous parent.  The moved dependency retains
   its weight.

   For example, consider an original dependency tree where B and C
   depend on A, D and E depend on C, and F depends on D.  If A is made
   dependent on D, then D takes the place of A.  All other dependency
   relationships stay the same, except for F, which becomes dependent on
   A if the reprioritization is exclusive.
Top   ToC   RFC7540 - Page 27
       x                x                x                 x
       |               / \               |                 |
       A              D   A              D                 D
      / \            /   / \            / \                |
     B   C     ==>  F   B   C   ==>    F   A       OR      A
        / \                 |             / \             /|\
       D   E                E            B   C           B C F
       |                                     |             |
       F                                     E             E
                  (intermediate)   (non-exclusive)    (exclusive)

                Figure 5: Example of Dependency Reordering

5.3.4.  Prioritization State Management

   When a stream is removed from the dependency tree, its dependencies
   can be moved to become dependent on the parent of the closed stream.
   The weights of new dependencies are recalculated by distributing the
   weight of the dependency of the closed stream proportionally based on
   the weights of its dependencies.

   Streams that are removed from the dependency tree cause some
   prioritization information to be lost.  Resources are shared between
   streams with the same parent stream, which means that if a stream in
   that set closes or becomes blocked, any spare capacity allocated to a
   stream is distributed to the immediate neighbors of the stream.
   However, if the common dependency is removed from the tree, those
   streams share resources with streams at the next highest level.

   For example, assume streams A and B share a parent, and streams C and
   D both depend on stream A.  Prior to the removal of stream A, if
   streams A and D are unable to proceed, then stream C receives all the
   resources dedicated to stream A.  If stream A is removed from the
   tree, the weight of stream A is divided between streams C and D.  If
   stream D is still unable to proceed, this results in stream C
   receiving a reduced proportion of resources.  For equal starting
   weights, C receives one third, rather than one half, of available

   It is possible for a stream to become closed while prioritization
   information that creates a dependency on that stream is in transit.
   If a stream identified in a dependency has no associated priority
   information, then the dependent stream is instead assigned a default
   priority (Section 5.3.5).  This potentially creates suboptimal
   prioritization, since the stream could be given a priority that is
   different from what is intended.
Top   ToC   RFC7540 - Page 28
   To avoid these problems, an endpoint SHOULD retain stream
   prioritization state for a period after streams become closed.  The
   longer state is retained, the lower the chance that streams are
   assigned incorrect or default priority values.

   Similarly, streams that are in the "idle" state can be assigned
   priority or become a parent of other streams.  This allows for the
   creation of a grouping node in the dependency tree, which enables
   more flexible expressions of priority.  Idle streams begin with a
   default priority (Section 5.3.5).

   The retention of priority information for streams that are not
   counted toward the limit set by SETTINGS_MAX_CONCURRENT_STREAMS could
   create a large state burden for an endpoint.  Therefore, the amount
   of prioritization state that is retained MAY be limited.

   The amount of additional state an endpoint maintains for
   prioritization could be dependent on load; under high load,
   prioritization state can be discarded to limit resource commitments.
   In extreme cases, an endpoint could even discard prioritization state
   for active or reserved streams.  If a limit is applied, endpoints
   SHOULD maintain state for at least as many streams as allowed by
   their setting for SETTINGS_MAX_CONCURRENT_STREAMS.  Implementations
   SHOULD also attempt to retain state for streams that are in active
   use in the priority tree.

   If it has retained enough state to do so, an endpoint receiving a
   PRIORITY frame that changes the priority of a closed stream SHOULD
   alter the dependencies of the streams that depend on it.

5.3.5.  Default Priorities

   All streams are initially assigned a non-exclusive dependency on
   stream 0x0.  Pushed streams (Section 8.2) initially depend on their
   associated stream.  In both cases, streams are assigned a default
   weight of 16.

5.4.  Error Handling

   HTTP/2 framing permits two classes of error:

   o  An error condition that renders the entire connection unusable is
      a connection error.

   o  An error in an individual stream is a stream error.

   A list of error codes is included in Section 7.
Top   ToC   RFC7540 - Page 29
5.4.1.  Connection Error Handling

   A connection error is any error that prevents further processing of
   the frame layer or corrupts any connection state.

   An endpoint that encounters a connection error SHOULD first send a
   GOAWAY frame (Section 6.8) with the stream identifier of the last
   stream that it successfully received from its peer.  The GOAWAY frame
   includes an error code that indicates why the connection is
   terminating.  After sending the GOAWAY frame for an error condition,
   the endpoint MUST close the TCP connection.

   It is possible that the GOAWAY will not be reliably received by the
   receiving endpoint ([RFC7230], Section 6.6 describes how an immediate
   connection close can result in data loss).  In the event of a
   connection error, GOAWAY only provides a best-effort attempt to
   communicate with the peer about why the connection is being

   An endpoint can end a connection at any time.  In particular, an
   endpoint MAY choose to treat a stream error as a connection error.
   Endpoints SHOULD send a GOAWAY frame when ending a connection,
   providing that circumstances permit it.

5.4.2.  Stream Error Handling

   A stream error is an error related to a specific stream that does not
   affect processing of other streams.

   An endpoint that detects a stream error sends a RST_STREAM frame
   (Section 6.4) that contains the stream identifier of the stream where
   the error occurred.  The RST_STREAM frame includes an error code that
   indicates the type of error.

   A RST_STREAM is the last frame that an endpoint can send on a stream.
   The peer that sends the RST_STREAM frame MUST be prepared to receive
   any frames that were sent or enqueued for sending by the remote peer.
   These frames can be ignored, except where they modify connection
   state (such as the state maintained for header compression
   (Section 4.3) or flow control).

   Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame
   for any stream.  However, an endpoint MAY send additional RST_STREAM
   frames if it receives frames on a closed stream after more than a
   round-trip time.  This behavior is permitted to deal with misbehaving
Top   ToC   RFC7540 - Page 30
   To avoid looping, an endpoint MUST NOT send a RST_STREAM in response
   to a RST_STREAM frame.

5.4.3.  Connection Termination

   If the TCP connection is closed or reset while streams remain in
   "open" or "half-closed" state, then the affected streams cannot be
   automatically retried (see Section 8.1.4 for details).

5.5.  Extending HTTP/2

   HTTP/2 permits extension of the protocol.  Within the limitations
   described in this section, protocol extensions can be used to provide
   additional services or alter any aspect of the protocol.  Extensions
   are effective only within the scope of a single HTTP/2 connection.

   This applies to the protocol elements defined in this document.  This
   does not affect the existing options for extending HTTP, such as
   defining new methods, status codes, or header fields.

   Extensions are permitted to use new frame types (Section 4.1), new
   settings (Section 6.5.2), or new error codes (Section 7).  Registries
   are established for managing these extension points: frame types
   (Section 11.2), settings (Section 11.3), and error codes
   (Section 11.4).

   Implementations MUST ignore unknown or unsupported values in all
   extensible protocol elements.  Implementations MUST discard frames
   that have unknown or unsupported types.  This means that any of these
   extension points can be safely used by extensions without prior
   arrangement or negotiation.  However, extension frames that appear in
   the middle of a header block (Section 4.3) are not permitted; these
   MUST be treated as a connection error (Section 5.4.1) of type

   Extensions that could change the semantics of existing protocol
   components MUST be negotiated before being used.  For example, an
   extension that changes the layout of the HEADERS frame cannot be used
   until the peer has given a positive signal that this is acceptable.
   In this case, it could also be necessary to coordinate when the
   revised layout comes into effect.  Note that treating any frames
   other than DATA frames as flow controlled is such a change in
   semantics and can only be done through negotiation.

   This document doesn't mandate a specific method for negotiating the
   use of an extension but notes that a setting (Section 6.5.2) could be
   used for that purpose.  If both peers set a value that indicates
   willingness to use the extension, then the extension can be used.  If
Top   ToC   RFC7540 - Page 31
   a setting is used for extension negotiation, the initial value MUST
   be defined in such a fashion that the extension is initially

(page 31 continued on part 3)

Next Section