Should the http2 spec state machine for stream lifecycle be separated into client and server?

Question

I was looking at the diagram here:

https://http2.github.io/http2-spec/#StreamStatesFigure

but throughout the documentation, servers send PUSH_PROMISE frames to clients not the other way around (at least not yet). This implies reserved (remote) state will ONLY happen on client software and reserved (local) state will only happen on server software. Is this true?

Ie. if I write a client, I am thinking I should really only have about 60% of the state machine for the client and 60% for the server (due to some overlap is why I say 60% and not 50%). Thoughts?

Answer 1

That's correct, from RFC 7540, section 8.2.1 Push Requests:

PUSH_PROMISE frames MUST NOT be sent by the client.

and, as you described, the RFC goes on:

Sending a PUSH_PROMISE frame creates a new stream and puts the stream into the "reserved (local)" state for the server and the "reserved (remote)" state for the client.

I'll just add that pushes can be disabled by the client by setting SETTINGS_ENABLE_PUSH to false in the SETTINGS frame. So if you're implementing your own client, it's also possible to entirely opt out from that part.

Answer 2

The answer to your first question is "yes", as Frederik has explained.

The statement

I am thinking I should really only have about 60% of the state machine for the client and 60% for the server

is not very accurate.

It's true that client will never enter the reserved(local) state, same for server with reserved(remote). However, in order to keep stream states synchronized, the simplest(maybe only) way is to also keep peer's state. In fact, stream state is not about one endpoint, but both. For any moment in a stream's life cycle, the stream's state is composed of client's state and server's state. Sometimes they are the same(idle, open, closed), sometimes they're not(reserved, half-closed).

With that said, I can understand why you say that, but you really shouldn't think that way. There's no client stream state and server stream state, just one stream state with copies saved on both sides.

It's kind of like a coin, with two sides having different images. No matter which direction you see from, the coin doesn't change, but you name the side you see "front side/local state", and the one you don't see "back side/remote state".

The "remote/local" wording in the state machine diagram is very subtle, and worth thinking over. Here's brief summary of what's important:

One state, two views, kept by two endpoints.
Should sync, could sync, often mismatch.