Search code examples
http2request-promise

http2: PUSH_PROMISE reserved stream id validation

The spec says:

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.

For the case of the server that sends PUSH_PROMISE it makes sense to me that conforming servers must send strictly increasing stream ids. But I don't understand how the client is supposed to detect this situation.

For example, on one connection, if the server sends:

  1. PUSH_PROMISE promised stream 2
  2. PUSH_PROMISE promised stream 4

because of concurrency the client might receive

  1. PUSH_PROMISE promised stream 4
  2. PUSH_PROMISE promised stream 2

the spec would have me think that client should error on this, but the server did nothing wrong.

What am I missing here?

Solution

  • If the server wrote PUSH_PROMISE[stream=2] and then PUSH_PROMISE[stream=4], then those frames will be delivered in the same order (this is guaranteed by TCP).

    It is a task of a client to read from the socket in an ordered way. For a HTTP/2 implementation the requirement is even stricter, in that not only it has to read from the socket in an ordered way, but it must also parse the frames in an ordered way.

    This is required by the fact that PUSH_PROMISE frame carries a HPACK block and in order to keep the server and client HPACK context in sync, the frames (or at least the HPACK blocks of those frames) must be processed in order, so stream=2 before stream=4.

    After that, the client is free to process the 2 frames concurrently.

    For implementations, this is actually quite simple to achieve, since a thread allocated to perform I/O reads typically does:

    loop
  read bytes from socket
  if no bytes or socket closed -> break loop
  parse read bytes (with HPACK decoding) -> produce frame objects
  pass frame objects to upper software layer
end loop

    Since the read and parse are sequential and no other thread reads from the same socket, the ordering guarantee is met.