Is HTTP/2 a stateless protocol?

Question

From my understanding, HTTP/2 comes with a stateful header compression called HPACK. Doesn't it change the stateless semantics of the HTTP protocol? Is it safe for web applications to consider HTTP/2 as a stateless protocol? Finally, will HTTP/2 be compatible with the existing load balancers?

Laconia

Answer 1

HTTP/2 is stateless.

Original HTTP is a stateless protocol, meaning that each request message can be understood in isolation. This means that every request needs to bring with it as much detail as the server needs to serve that request, without the server having to store a lot of info and meta-data from previous requests.

Since HTTP/2 doesn't change this paradigm, it has to work the same way, stateless.

It's clearly visible from official RFCs as well. It is stated:

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks...

and the definition of HTTP/2 says:

This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2)... This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.

Conclusion

HTTP/2 protocol is stateless by design, as semantics remain unchanged in comparison to original HTTP.

---

From where confusion may come

An HTTP/2 connection is an application-layer protocol running on top of a TCP connection (BTW, nothing stops you to use HTTP over UDP for example, it's possible, but UDP is not used because it is not a "reliable transport"). Don't mix it with session and transport layers. HTTP protocol is stateless by design. HTTP over an encrypted SSL/TLS connection, also changes nothing to this statement, as S in HTTPS is concerned with the transport, not the protocol itself.

HPACK, Header Compression for HTTP/2, is a compression format especially crafted for HTTP/2 headers, and it is being specified in a separate internet draft. It doesn't change HTTP/2 itself, so it doesn't change the semantics.

In RFC for HTTP/2 in section about HPACK they state:

Header compression is stateful. One compression context and one decompression context are used for the entire connection.

And here's why from HPACK's RFC:

2.2. Encoding and Decoding Contexts

To decompress header blocks, a decoder only needs to maintain a dynamic table (see Section 2.3.2) as a decoding context. No other dynamic state is needed.

When used for bidirectional communication, such as in HTTP, the encoding and decoding dynamic tables maintained by an endpoint are completely independent, i.e., the request and response dynamic tables are separate.

---

HPACK reduces the length of header field encoding by exploiting the redundancy inherent in protocols like HTTP. The ultimate goal of this is to reduce the amount of data that is required to send HTTP requests or responses.

An HPACK implementation cannot be completely stateless, because the encoding and decoding tables, completely independent, have to be maintained by an endpoint.

At the same time, there are libraries, which try to solve HPACK issues, for example, a stateless event-driven HPACK codec CASHPACK:

An HPACK implementation cannot be completely stateless, because a dynamic table needs to be maintained. Relying on the assumption that HTTP/2 will always decode complete HPACK sequences, statelessness is achieved using an event-driven API.

Initial

I think the HPACK section of this answer (+1) is going in the wrong direction. Clearly, there is state. But the state is per connection and not per server or session. Per connection state is nothing new. Every TCP connection has that. Also, the state is expendable. – Tress

@usr, good input, regarding state per connection, I wasn't managed to formulate this thought... If you don't mind, I'll extend my answer, based on your input. Thanks. – Initial

Thank you @Tress @Farside! The state per TCP connection explains everything :) I guess it would be better to mention it at the beginning of HPACK section. – Laconia

@zeronone, thank you! I'd prefer to be sequential :) the last is an outcome of previous investigations and facts. – Initial

@Farside. HTTP/2 is is absolutely a stateful protocol. A specific HTTP/2 application does not need to use stateful features and can be stateless, but the HTTP/2 protocol itself does define stateful components and is therefor stateful. – Mulford

@Zamicol, you are forming conjecture without firm evidence. Please, learn OSI model first. An HTTP/2 connection is an application-layer protocol running on top of a TCP connection (BTW, nothing stops you to use HTTP over UDP for example, it's possible, but UDP is not used because it is not a "reliable transport"). Don't mix it with session and transport layers. HTTP protocol is stateless by design. HTTP over an encrypted SSL/TLS connection, for example, also changes nothing to this statement, as S in HTTPS is concerned with the transport, not the protocol itself. – Initial

@Initial The "OSI model" has nothing to do with it. HTTP/2 defines stateful mechanisms. If a single part of a protocol is stateful, the entire protocol is stateful, although there may be stateless components. See tools.ietf.org/html/rfc7540#section-5.1 for stateful mechanisms in HTTP/2. "Please, learn OSI model first. " Please stop assuming. – Mulford

@Initial Going through the google docs regarding HTTP/2 protocol. They have clearly emphasized on the fact that HTTP/2 does support multiple streams over one TCP connection. developers.google.com/web/fundamentals/performance/http2 – Monroe

You reference HTTP 1 as a source for statelessness, not the HTTP 2 RFC. This answer is made in bad faith. – Mulford

@Zamicol, the streaming capability does not imply statefulness. While HTTP/2 introduces new features and optimizations over HTTP/1.1, such as header compression and server push, it does not fundamentally change the stateless nature of the HTTP protocol. Each request and response in HTTP/2 is still treated independently, without maintaining any persistent state between them. Read the RTF, and try to understand its meaning, not just search for the keywords "stateless" and "state". – Initial

Answer 2

HTTP/2 is stateful. HTTP 1 was stateless.

Theory aside, in practice you use HTTP statefully in your everyday life.

HTTP 1 is colloquially said to be stateless although in practice we've been using standardized stateful mechanisms for almost three decades. Instead of saying "HTTP is stateless", it's more honest to say "HTTP originally defined a stateless core that has since incorporated numerous stateful additions. Modern HTTP usage is stateful." Netscape introduced cookies in 1994 which formally introduced state to HTTP. Cookies are the means that first formally allowed HTTP to transform from stateless to stateful, but since cookies were an addition it was still colloquially said that HTTP was stateless even though after the introduction of cookies stateful HTTP quickly became the norm for the majority of HTTP Internet traffic. Also note, after the introduction of cookies we didn't start saying "HTTP plus cookies", we continued to just say "HTTP" because it was understood that cookies were now incorporated into the HTTP standard even though it was an addition. As time progressed, many more stateful components were added for performance and security.

So understanding this usage reality, HTTP/2 abandoned stateless goals. Many HTTP/2 components are the very definition of stateful. Unlike the original HTTP/1.0, HTTP/2 defines stateful components in its standard and is therefore stateful. No longer are the stateful components "additions", instead stateful components are defined in the core of the HTTP/2 standard. HTTP/2 is littered with stateful components. The errant "HTTP is stateless" is old-time dogma, far from the modern stateful reality of HTTP.

There are 125 references to "state" and zero references to "stateless" in the HTTP/2 specification (RFC 7540).

Here's a limited, not exhaustive, list of stateful HTTP/1 and HTTP/2 components:

• The HTTP/2 RFC plainly says header Compression is stateful.
• The purpose of HTTP/2 stream identifiers is state. (A whole section is dedicated to various states.)
• HTTP/2 headers, which establish stream identifiers, are stateful. (Just one example from the RFC: "HEADERS frames can be sent on a stream in the "idle", "reserved (local)", "open", or "half-closed (remote)" state.")
• HTTP/2 Frames are stateful. Just one example from the RFC, "The transmission of specific frame types can alter the state of a connection."
• Cookies are stateful and the specification is titled, "HTTP State Management Mechanism" (RFC 6265).
• HTTPS, which stores keys thus state, is stateful. Also note the whole point of the CA system which is required for HTTPS is state management.
• HTTP authentication requires state. (It's so obvious it's overlooked.)
• Web Storage is stateful. (It's so obvious it's overlooked.)
• HTTP caching is stateful. Caching by definition is stateful. (It's so obvious it's overlooked.)
• Opportunistic encryption is stateful.
• URL parameters are stateful. This is how applications accomplished state before the first formal stateful mechanism (Cookies) in 1994. Even if not using any other stateful HTTP features, if using URL parameters statefully, that HTTP application 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 to assume an arbitrary HTTP/2 applications is stateless?

HTTP/2 is a stateful protocol, but that doesn't mean your HTTP/2 application can't be stateless. You can choose to ignore stateful features in order to make stateless HTTP/2 applications.

Even though you can define your own application to be stateless, you should not assume an arbitrary HTTP/2 application is stateless. In fact, all popular websites will break if used statelessly, so it's better to assume is that a HTTP/2 application is stateful.

The same even applies to HTTP 1. Even though it is colloquially said that HTTP 1 is stateless, it is not be safe to assume that an arbitrary HTTP 1 application is stateless and almost all applications will break if trying to use them statelessly. For example, You cannot use Facebook with stateless HTTP. Stateful HTTP is a requirement to use Facebook. Wikipedia, Google, WolframAlpha, Khan Academy, Youtube, Amazon, Facebook, etc... all use stateful HTTP. DuckDuckGo may be the only popular website that does not require stateful HTTP for basic functionality, but even then login and other functionality is broken without stateful HTTP.

TL;DR:

Stateful mechanisms were later HTTP additions over the original stateless standard. HTTP/1 is colloquially said to be stateless although in practice we've used standardized stateful mechanisms, like cookies and caching for nearly three decades. Stateless HTTP isn't very useful or efficient in the modern world, so unlike HTTP/1, HTTP/2 defines stateful components in its standard from the very beginning. A particular HTTP/2 application can ignore HTTP/2 features to maintain statelessness, but the protocol itself anticipates state to be the norm, not the exception. Modern HTTP usage is stateful. Old timey HTTP was stateless.

Mulford

Cookies are send along with every request, so the HTTP is stateless. The applications working on the top of HTTP is of course stateful. But I was interested in the HTTP itself, such that if the load balancer send the consequent requests to differnet machines would it be any problem. HTTP/2 preseves the statless semantics, so it doesnt matter which instance or machine the consequent requests are routed. In other words the state is confined to a single TCP connection, consequent connections are independent. – Laconia

haha, Zamicol, you made me laugh on "HTTP RFC says nothing about cookies" ... of course it doesn't, no wonder! =) You are speculating on the subject, without understanding of OSI model, it seems. HTTP/1.0 is not stateful. The same is fully true about HTTP/2, as application layer still remains stateless... however it does have a few stateful components according to RFC, which is also true. An HTTP/2 connection is an application-layer protocol running on top of a TCP connection. Don't mix it with session and transport layers. Also read what @Laconia written above. Get the down-vote. – Initial

@Laconia Cookies are stateful. "send along with every request" is how your browser accomplishes state. Cookies were an addition created after HTTP/1.0. HTTP/2 introduces new stateful mechanisms over what was accomplished with HTTP/1.0. – Mulford

@Initial "HTTP/2, as application layer still remains stateless... however it does have a few stateful components according to RFC" I wrote the answer that you are paraphrasing. You are citing me as a source of your contention. https://mcmap.net/q/128428/-is-https-stateful-or-stateless – Mulford

I think the confusion stems from which direction you look at the protocol. All of this is transparent to the client and server application, through abstraction layered at least similar to the OSI model. The code required for issuing a request from JavaScript and handling that in a web application written in Python doesn't need to know which HTTP version is used and how many frames flow around various streams over who knows how many connections. You're right in that browser and client need to maintain a state about connections, but whether that makes HTTP/2 "stateful" depends on who's asking. – Faye

The evidence of 125 matches for state and 0 finds of stateless sounds like a silly student answer about HTTP2. HTTP/1.1 also mentions stateless and state in proportion 1 to 42 hits in RFC, does it mean old HTTP also more stateful than stateless? haha, what a joke!! The streaming capability does not imply statefulness. While HTTP/2 introduces new features and optimizations over HTTP/1.1, such as header compression and server push, it does not fundamentally change the stateless nature of the HTTP protocol, each request/response is still treated independently without state – Initial