Modern HTTP is stateful. Old timey HTTP was stateless.
Before Netscape invented cookies and HTTPS in 1994 http could be considered stateless. As time progressed more and more stateful aspects were added for a myriad of reasons, including performance and security.
While HTTP 1 originally sought out to be stateless many HTTP/2 components are the very definition of stateful. HTTP/2 abandoned stateless goals.
No reasonable person can read the HTTP/2 RFC and think it is stateless. The errant "HTTP is stateless" old time dogma is false and far from the current reality of stateful HTTP.
Here's a limited, and not exhaustive list, of stateful HTTP/1 and HTTP/2 components:
- Cookies, named "HTTP State Management Mechanism" by the RFC.
- HTTPS, which stores keys thus state.
- HTTP authentication requires state.
- Web Storage.
- HTTP caching is stateful.
- The very purpose of the stream identifier is state. It's even in the name of the RFC section, "Stream States".
- Header blocks, which establish stream identifiers, are stateful.
- Frames which reference stream identifiers are stateful.
- Header Compression, which the HTTP RFC explicitly says is stateful, is stateful.
- Opportunistic encryption is stateful.
Section 5.1 of the HTTP/2 RFC is a great example of stateful mechanisms defined by the HTTP/2 standard.
Is it safe for web applications to consider HTTP/2 as a stateless protocol?
HTTP/2 is a stateful protocol, but that doesn't mean your HTTP/2 application can't be stateless. You can choose to not use certain stateful features for stateless HTTP/2 applications by using only a subset of HTTP/2 features.
Cookies and some other stateful mechanisms, or less obvious stateful mechanisms, are later HTTP additions. HTTP 1 is said to be stateless although in practice we use standardized stateful mechanisms, like cookies, TLS, and caching. Unlike HTTP/1, HTTP/2 defines stateful components in its standard from the very beginning. A particular HTTP/2 application can use a subset of HTTP/2 features to maintain statelessness, but the protocol itself anticipate state to be the norm, not the exception.
Existing applications, even HTTP 1 applications, needing state will break if trying to use them statelessly. It can be impossible to log into some HTTP/1.1 websites if cookies are disabled, thus breaking the application. It may not be safe to assume that a particular HTTP 1 application does not use state. This is no different for HTTP/2.
Say it with me one last time:
HTTP/2 is a stateful protocol.