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

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.

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.

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.

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.

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.

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 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 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.

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, "Stream States", of the HTTP/2 RFC is a great example of a stateful mechanism defined by the HTTP/2 standard. Section 5.3.4 is even titled "Prioritization State Management".

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 stateful features for stateless HTTP/2 applications.

Existing HTTP/1 and HTTP/2 applications needing state will break if attempting to use them statelessly. For example, 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 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, 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 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.

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.

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.

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.

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.

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