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.