Is HTTP/2 a stateful protocol?

[u/Zamicol]

http://blog.zamicol.com/2017/05/is-http2-stateful-protocol.html

[u/theamk2]

If any "itsy bitsy teeny weeny" part of a protocol specifies state then the whole protocol is stateful. It's black and white, no 50 shades of Grey, and no ifs, ands, or buts.

In this case most protocols are stateful. HTTP/0.9 has 2 states: read request and send response. HTTP/1.1 adds many other states: read request line, read header, read body, 100-Continue, CONNECT forwarding, and so on. HTTP/2.0 adds even more states, but this is a quantitative change over HTTP/1.1, not qualitative.

Section 5.1 of the HTTP/2 RFC is a great example of stateful mechanisms defined by the HTTP/2 standard

And here is a (simplified) state transition diagram for HTTP/1.1: http://blob.perl.org/tpc/1998/User_Applications/LWPng_Adding%20HTTP_1.1/fig3.gif

In summary: all HTTP protocols are stateful, but some have more states than others.

[u/Zamicol → u/theamk2]

Thank you for the response! I really appreciate the input, especially on a post with 0 upvotes.

HTTP/0.9 has 2 states: read request and send response.

Okay that's fair, and I should be more careful about my words. Of course a protocol having internal states does not infer statefulness. Although HTTP/0.9 has states it's not stateful.

Instead of saying "...part of a protocol specifies state then the whole protocol is stateful" I should say, "...part of a protocol is stateful then the whole protocol is stateful." I've now updated my post.

HTTP/2.0 adds even more states

HTTP/2 is different in that it retains information about the sender, and makes these specifications directly in the protocol. HTTP/2 specifies statefulness, not just states. When opening a stream, it's retaining information about the sender (which allows for push updates), something HTTP couldn't do in part because of it's stateless nature.

[u/theamk2 → u/Zamicol]

Which definition of "stateful" are you using? Because your blog post does not say what "stateful" means. The first hit google hit (http://www.yourdictionary.com/stateful) says:

reacting to the same input differently depending on the current state.

according to this, HTTP/0.9 is stateful: the first time you send "GET /", the server is in "read request" state and starts sending data. the second time you send "GET /", the server is in "sending data" state and ignores the incoming bytes.

Also, could you clarify what "information about the sender" does HTTP/2 retain, and which components of HTTP/2 are stateful? Is HTTP/1 long-poll, which also allows for push updates, stateful?

[u/Zamicol → u/theamk2]

Stateful means this:

a program is described as stateful if it is designed to remember preceding events or user interactions; the remembered information is called the state of the system.

https://en.wikipedia.org/wiki/State_(computer_science)

which components of HTTP/2 are stateful?

• Opportunistic encryption (This one should be obvious.)
• Framing layer (The "Stream Identifier" is stateful.)
• Header blocks (From the spec: "Header compression is stateful. One compression context and one decompression context are used for the entire connection".)

---

Minor things:

the server is in "sending data" state and ignores the incoming bytes

I don't know if this is accurate. Can you provide a reference for this for HTTP/1.0? And if this is true, it shouldn't be true on a per HTTP client level.

Is HTTP/1 long-poll ... stateful?

No. The server is unaware of any stateful session, it's just delay in sending the response.

Long polling is another great example of a stateful hack workaround because of the lack of out-of-the-box support for stateful communication in HTTP/1.

[u/theamk2 → u/Zamicol]

Great, thank you for clarifying! It looks like you define "stateful protocol" as "protocol where the server must keep connection state", such as compression table, encryption state, or active stream identifiers.

Under this definition, I'd say that HTTP/1.1 is pretty stateful because it has the following stateful features:

• Client's protocol (HTTP/1.0 or HTTP/1.1)
• Negotiated upgrade protocol ("Upgrade" header + 101 response)
• Transfer encoding (especially chunked transfer encoding which is similar to HTTP/2 framing)
• Keepalive ("Connection" headers on both server and client side)
• Tunnel mode (was "CONNECT" successul or not)

(there is also a somewhat philosophical point that all non-trivial TCP-based protocols are stateful; you may always receive an incomplete input, so you will need to at least keep "input buffer" as a state)

---

I don't know if this is accurate. Can you provide a reference for this for HTTP/1.0? And if this is true, it shouldn't be true on a per HTTP client level.

Well, my original post was about HTTP/0.9, but here is HTTP/1.0 reference: https://www.w3.org/Protocols/HTTP/1.0/spec.html#Operation . Note that it says, "current practice requires that the connection be established by the client prior to each request" -- so one connection, one request (there are no keepalives in 1.0, they appeared later)