Why is it said that "HTTP is a stateless protocol"?

Question

HTTP has HTTP Cookies. Cookies allow the server to track the user state, the number of connections, last connection, etc.

HTTP has persistent connections (Keep-Alive) where several requests can be sent from the same TCP Connection.

Solipsism

Another area where I don't see "stateless-ness" is in Authorization - particularly Proxy-Authorization. It seems that it is stateful during the negotiation. For NTLM Authentication, the client needs to remember the type of Proxy-Authentication and the server needs to be stateful since there is a sequence to the NTLM Message Types. So I'm not sure I understand the answers. – Miracle

Should I now add HTTP/1.1? Because I think HTTP/2 has state. – Solipsism

HTTP/2 is stateful. HTTP 1 is stateless. Later additions intended for HTTP 1, like cookies, added state. Those additions are not apart of the "core" HTTP 1 specification. This is why HTTP 1 is said to be a stateless protocol although in practice it is not. HTTP/2 on the other hand was designed with stateful components baked in. No additions were required to satisfy the requirement of being labeled "stateful". – Cere

Also related: #11068000 #36178947 – Ellerd

Answer 1

Even though multiple requests can be sent over the same HTTP connection, the server does not attach any special meaning to their arriving over the same socket. That is solely a performance thing, intended to minimize the time/bandwidth that'd otherwise be spent reestablishing a connection for each request.

As far as HTTP is concerned, they are all still separate requests and must contain enough information on their own to fulfill the request. That is the essence of "statelessness". Requests will not be associated with each other absent some shared info the server knows about, which in most cases is a session ID in a cookie.

Streaming

What happens when the server remembers a session (server-side) and customizes user experience according to it? – Ozonolysis

@NurShomik: See https://mcmap.net/q/128430/-how-does-iis-recognize-different-sessions-in-net for an explanation of how sessions typically work. – Streaming

@Andrew: HTTP is not "built on" TCP, and TCP's state is not HTTP's. The two are entirely separate protocols at different layers in the stack. You could serve HTTP over named pipes if you wanted, or even by sending files around, if you got enough masochists to agree to do it, and it would work precisely because HTTP is transport-protocol-agnostic. At that level, it's all just requests and responses. That makes HTTP itself stateless, regardless of what state may be used/maintained/required by lower- or higher-level protocols. – Streaming

@Streaming Okay, I'll concede. If we define statelessness as "not necessarily needing to have state in order to operate" (see dimo414's answer below listing options for state within HTTP cited from Wikipedia), and if we view each protocol strictly by itself and not based upon the layers below it, then yes, I can agree that HTTP is "stateless". – Ellerd

Answer 2

From Wikipedia:

HTTP is a stateless protocol. A stateless protocol does not require the server to retain information or status about each user for the duration of multiple requests.

But some web applications may have to track the user's progress from page to page, for example when a web server is required to customize the content of a web page for a user. Solutions for these cases include:

• the use of HTTP cookies.
• server side sessions,
• hidden variables (when the current page contains a form), and
• URL-rewriting using URI-encoded parameters, e.g., /index.php?session_id=some_unique_session_code.

What makes the protocol stateless is that the server is not required to track state over multiple requests, not that it cannot do so if it wants to. This simplifies the contract between client and server, and in many cases (for instance serving up static data over a CDN) minimizes the amount of data that needs to be transferred. If servers were required to maintain the state of clients' visits the structure of issuing and responding to requests would be more complex. As it is, the simplicity of the model is one of its greatest features.

Mimosa

Seems like they should've just not so officially declared it as a stateless protocol and instead, used some word stating that it is flexible to switch between stateless vs. stateful. – Sigil

Answer 3

HTTP is called as a stateless protocol because each request is executed independently, without any knowledge of the requests that were executed before it, which means once the transaction ends the connection between the browser and the server is also lost.

What makes the protocol stateless is that in its original design, HTTP is a relatively simple file transfer protocol:

1. make a request for a file named by a URL,
2. get the file in response,
3. disconnect.

There was no relationship maintained between one connection and another, even from the same client. This simplifies the contract between client and server, and in many cases minimizes the amount of data that needs to be transferred.

Katlin

This is not true, especially HTTP/2 where request depend on other requests. Cookies, HTTPS, HTTP authentication, Web Storage, HTTP caching, HTTP stream identifiers, HTTP/2 header blocks, HTTP/2 frames, header compression, and opportunistic encryption are all stateful. – Cere

Answer 4

Because a stateless protocol does not require the server to retain session information or status about each communications partner for the duration of multiple requests.

HTTP is a stateless protocol, which means that the connection between the browser and the server is lost once the transaction ends.

Mallemuck

But, HTTP can save information in server, using cookies. HTTP wih keep-alive don't close connection on each request. – Solipsism

Check out this article:- ecst.csuchico.edu/~amk/foo/advjava/notes/servlets/Cookies.html – Mallemuck

Saving information on server does not mean that the connection is alive constantly. – Gag

@Gag Well, no. So? Nobody was claiming otherwise. – Astor

Answer 5

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, many stateful components were formally added for a myriad of reasons, including performance and security. But the stateful additions were just that, additions, so it was still colloquially said that HTTP was stateless because the original core explicitly sought out to be stateless.

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 longer are the stateful components "additions", instead stateful components are defined in the core of the HTTP/2 standard. 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 useing 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 for web applications to consider HTTP/2 as a stateless protocol?

HTTP/2 is a stateful protocol, but your HTTP/2 application can ignore stateful features to maintain statelessness.

Existing HTTP/1 and HTTP/2 applications needing state will break if attempting to use them statelessly. For example, it can be impossible to login to 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 or HTTP/2 application is stateless.

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 use standardized stateful mechanisms, like cookies 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 anticipates state to be the norm, not the exception. The errant "HTTP is stateless" is old-time dogma, far from the modern stateful reality of HTTP and theory aside, in practice you use HTTP statefully in your everyday life.

Cere

"HTTPS, which stores keys thus state". Mh, no has nothing ot do with HTTP. HTTPS = HTTP over TLS. The key "storage" happens in another protcol layer. en.wikipedia.org/wiki/HTTPS#Difference_from_HTTP – Bawd

this is a reasonable answer. But why does nobody support this? – Paramatta

If HTTP is a stateful protocol how does client side load balancing work? Client sends request randomly to any of the end servers and everything works just fine. – Briquette

HTTP/2 is STATELESS. Discussed and resolved here: https://mcmap.net/q/128429/-is-http-2-a-stateless-protocol – Septimal

@Septimal Obviously HTTP/2 is stateful, but in your mind, what would a stateful HTTP look like? What would the requirement be for HTTP to become stateful? – Cere

Answer 6

If protocol HTTP is given as State full protocol,browser window uses single connection to communicate with web server for multiple request given to web application.this gives chance to browser window to engage the connections between browser window and web servers for long time and to keep them in idle state for long time.This may create the situation of reaching to maximum connections of web server even though most of the connections in clients are idle.

Tunicle

HTTP already have keep-alive, this mean that server doesn't close the connection, and client can makes many request on the same connection. – Solipsism

Answer 7

HTTP is stateless. TCP is stateful. There is no so-called HTTP connection, but only HTTP request and HTTP response. We don't need anything to be maintained to make another HTTP request. A connection header that is "keep-alive" means the TCP will be reused by the subsequent HTTP requests and responses, instead of disconnecting and re-establishing TCP connection all the time.

Hyperborean

HTTP/2 is stateful and does have a HTTP connection, called a stream. tools.ietf.org/html/rfc7540#section-5.1 – Cere

Answer 8

HTTP is a connectionless and this is a direct result that HTTP is a stateless protocol. The server and client are aware of each other only during a current request. Afterwards, both of them forget about each other. Due to this nature of the protocol, neither the client nor the browser can retain information between different request across the web pages.

Velazquez

Answer 9

I think somebody chose very unfortunate name for STATELESS concept and that's why the whole misunderstanding is caused. It's not about storing any kind of resources, but rather about the relationship between the client and the server.

Client: I'm keeping all the resources on my side and send you the "list" of all the important items which need to processed. Do your job.

Server: All right.. let me take the responsibility on filtering what's important to give you the proper response.

Which means that the server is the "slave" of the client and has to forget about his "master" after each request. Actually, STATELESS refers only to the state of the server.

https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_1_3

Breechloader

Answer 10

What is stateless??

Once the request is made and the response is rendered back to the client the connection will be dropped or terminated. The server will forget all about the requester.

Why stateless??

The web chooses to go for the stateless protocol. It was a genius choice because the original goal of the web was to allow documents(web pages) to be served to extremely large no. of people using very basic hardware for the server.

Maintaining a long-running connection would have been extremely resource-intensive.

If the web were chosen the stateful protocol then the load on the server would have been increased to maintain the visitor's connection.

Putty